Physically unclonable functions

ABSTRACT

A method for enabling a verifying party to verify an identity of a target party or device. The method comprises, in a set-up phase: storing, in a data store, a respective piece of response data for each of a set of one or more responses resulting from a setting-up party inputting a respective set of one or more challenges into a PUF module comprising a physically unclonable function, PUF, to generate the one or more responses based on the PUF; and storing an indication of the set of challenges in the data store. The indication does not comprise a value of each of the challenges in the set, but rather a master challenge from which the set of challenges is derivable by applying a derivation function to the master challenge.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is the U.S. National Stage of International ApplicationNo. PCT/EP2021/073961 filed on Aug. 31, 2021, which claims the benefitof United Kingdom Patent Application No. 2015475.3, filed on Sep. 30,2020, the contents of which are incorporated herein by reference intheir entireties.

TECHNICAL FIELD

The present disclosure relates to the field of physically unclonablefunctions, PUFs.

BACKGROUND

A physically unclonable function (PUF) is a term of art referring to afunction comprising a deterministic but unpredictable physicalphenomenon. A PUF is also sometimes referred to as a physical randomfunction. A PUF receives an input, referred to as a “challenge”, andgenerates an output, referred to as the corresponding “response”, independence on the challenge and the physical phenomenon employed by thePUF. PUFs are sometimes classified into strong and weak PUFs. A strongPUF is capable of generating a respective response for a large number ofdifferent challenges, typically being able to take any arbitrary valueof the challenge. A weak PUF can generate a response for only a singleresponse or a small number of responses (typically the challenge cannottake any arbitrary value). In other words, a strong PUF has a largenumber of challenge-response pairs (it has a large challenge-responsespace), whilst a weak PUF has a single challenge-response pair orlimited number of challenge-response pairs (a small or limitedchallenge-response space). According to one definition, a weak PUF has anumber of responses linear in the number of challenge bits, or moregenerally one that does not grow more than linearly in other parameters.

A known example of a strong PUF is an optical PUF. For instance, anoptical PUF may comprise a laser, an optical sensor, and a solid opticalmedium with bubbles or other such artefacts set in the medium. The laseris shone through the optical medium at a controllable angle to create adiffraction or scattering pattern (which is an effect of the bubbles orartefacts in the medium). The sensor is arranged to sense this pattern.The challenge is the angle of the laser, and the response is generatedbased on the sensed pattern.

An example of a weak PUF is an SRAM PUF. In this case the challenge isturning on the SRAM (static random access memory). Due to slightmanufacturing differences from one SRAM to another, then the SRAM cellswill happen to fall into a unique pattern of 0/1 states upon power up,which thus forms a characteristic fingerprint of the individual SRAM.The PUF is configured to output this as the response upon power-up.

A PUF can be used as a means to generate a key, such as for use incryptographic algorithms (e.g. to sign or encrypt a document). Anotherapplication of a PUF is for identification of a device such as acomputer device that incorporates the PUF. If the expected response fora given challenge has previously been determined, then a verifying partycan later challenge a target device with the challenge and check whetherit gives the expected response, and thereby check whether the targetdevice is the device associated with the expected response.

Because of the limited challenge response space, the input-output (i/o)interface to a weak PUF tends to be restricted to only one or arestricted number of parties (e.g. only one or a limited number oftrusted parties may be physically or legally granted access to the PUF,or the interface to the PUF may be password protected or the like). I.e.only the party or parties in question can gain access to the input tothe PUF needed to submit the challenge and the output from which theresponse is received back. For strong PUFs on the other hand, the i/ointerface to a strong PUF may be made widely available to a large orunlimited number of parties, not all of whom are necessarily known ortrusted parties. The reason is that the challenge response space islarge enough that it is infeasible for an adversary to enumerate all ofthe challenge-response pairs, and therefore the ability for an adversaryto freely access the PUF should not compromise its security by allowingan enumeration and spoofing of the PUF, as would be the case for weakPUFs.

In a different area of technology, a blockchain refers to a form ofdistributed data structure whereby a duplicate copy of the blockchain ismaintained at each of a plurality of nodes in a distributed peer-to-peer(P2P) network (referred to below as a “blockchain network”) and widelypublicised. The blockchain comprises a chain of blocks of data, whereineach block comprises one or more transactions. Each transaction, otherthan so-called “coinbase transactions”, points back to a precedingtransaction in a sequence which may span one or more blocks going backto one or more coinbase transactions. Coinbase transactions arediscussed further below. Transactions that are submitted to theblockchain network are included in new blocks. New blocks are created bya process often referred to as “mining”, which involves each of aplurality of the nodes competing to perform “proof-of-work”, i.e.solving a cryptographic puzzle based on a representation of a definedset of ordered and validated pending transactions waiting to be includedin a new block of the blockchain. It should be noted that the blockchainmay be pruned at some nodes, and the publication of blocks can beachieved through the publication of mere block headers.

The transactions in the blockchain may be used for one or more of thefollowing purposes: to convey a digital asset (i.e. a number of digitaltokens), to order a set of entries in a virtualised ledger or registry,to receive and process timestamp entries, and/or to time-order indexpointers. A blockchain can also be exploited in order to layeradditional functionality on top of the blockchain. For exampleblockchain protocols may allow for storage of additional user data orindexes to data in a transaction. There is no pre-specified limit to themaximum data capacity that can be stored within a single transaction,and therefore increasingly more complex data can be incorporated. Forinstance this may be used to store an electronic document in theblockchain, or audio or video data.

Nodes of the blockchain network (which are often referred to as“miners”) perform a distributed transaction registration andverification process, which will be described in more detail later. Insummary, during this process a node validates transactions and insertsthem into a block template for which they attempt to identify a validproof-of-work solution. Once a valid solution is found, a new block ispropagated to other nodes of the network, thus enabling each node torecord the new block on the blockchain. In order to have a transactionrecorded in the blockchain, a user (e.g. a blockchain clientapplication) sends the transaction to one of the nodes of the network tobe propagated. Nodes which receive the transaction may race to find aproof-of-work solution incorporating the validated transaction into anew block. Each node is configured to enforce the same node protocol,which will include one or more conditions for a transaction to be valid.Invalid transactions will not be propagated nor incorporated intoblocks. Assuming the transaction is validated and thereby accepted ontothe blockchain, then the transaction (including any user data) will thusremain registered and indexed at each of the nodes in the blockchainnetwork as an immutable public record.

The node who successfully solved the proof-of-work puzzle to create thelatest block is typically rewarded with a new transaction called the“coinbase transaction” which distributes an amount of the digital asset,i.e. a number of tokens. The detection and rejection of invalidtransactions is enforced by the actions of competing nodes who act asagents of the network and are incentivised to report and blockmalfeasance. The widespread publication of information allows users tocontinuously audit the performance of nodes. The publication of the mereblock headers allows participants to ensure the ongoing integrity of theblockchain.

In an “output-based” model (sometimes referred to as a UTXO-basedmodel), the data structure of a given transaction comprises one or moreinputs and one or more outputs. Any spendable output comprises anelement specifying an amount of the digital asset that is derivable fromthe proceeding sequence of transactions. The spendable output issometimes referred to as a UTXO (“unspent transaction output”). Theoutput may further comprise a locking script specifying a condition forthe future redemption of the output. A locking script is a predicatedefining the conditions necessary to validate and transfer digitaltokens or assets. Each input of a transaction (other than a coinbasetransaction) comprises a pointer (i.e. a reference) to such an output ina preceding transaction, and may further comprise an unlocking scriptfor unlocking the locking script of the pointed-to output. So consider apair of transactions, call them a first and a second transaction (or“target” transaction). The first transaction comprises at least oneoutput specifying an amount of the digital asset, and comprising alocking script defining one or more conditions of unlocking the output.The second, target transaction comprises at least one input, comprisinga pointer to the output of the first transaction, and an unlockingscript for unlocking the output of the first transaction.

In such a model, when the second, target transaction is sent to theblockchain network to be propagated and recorded in the blockchain, oneof the criteria for validity applied at each node will be that theunlocking script meets all of the one or more conditions defined in thelocking script of the first transaction. Another will be that the outputof the first transaction has not already been redeemed by another,earlier valid transaction. Any node that finds the target transactioninvalid according to any of these conditions will not propagate it (as avalid transaction, but possibly to register an invalid transaction) norinclude it in a new block to be recorded in the blockchain.

An alternative type of transaction model is an account-based model. Inthis case each transaction does not define the amount to be transferredby referring back to the UTXO of a preceding transaction in a sequenceof past transactions, but rather by reference to an absolute accountbalance. The current state of all accounts is stored by the nodesseparate to the blockchain and is updated constantly.

SUMMARY

According to one aspect disclosed herein, there is provided acomputer-implemented method for enabling one or more verifying partiesto verify an identity of a target comprising a target party or device ofthe target party. The method comprises, in a set-up phase: storing, in adata store, a respective piece of response data for each of a set of oneor more responses resulting from a setting-up party inputting arespective set of one or more challenges into a PUF module comprising aphysically unclonable function, PUF, to generate the one or moreresponses based on the PUF. The method further comprises: storing anindication of the set of challenges in the data store, wherein theindication does not comprise a value of each of the challenges in theset, but rather a master challenge from which the set of challenges isderivable by applying a derivation function to the master challenge;thereby making at least one of the pieces of response data and therespective master challenge available to the one or more verifyingparties for verifying the identity of the target in a subsequentverification phase. The respective piece of response data for eachresponse may comprise the respective response itself or data derivedtherefrom.

The method thus provides a lightweight means of storingchallenge-response (CR) pairs or the like, which does not require thechallenge to be explicitly stored for every response.

In embodiments, the master challenge may comprise identificationinformation of the target, e.g. passport information, biometricinformation or secret personal information (e.g. mother's maiden name)of the target party. This way a set of challenges can readily beprovided that is unique to the particular target, such as to enabledifferent sets of challenges to be derived for multiple differenttargets. The identification information may comprise information thatthe target party already knows or keeps secure (e.g. secret).

In embodiments the data store may comprise a peer-to-peer publicationmedium such as a blockchain. Alternatively the data store could beimplemented in trusted third party computer equipment (e.g. a server ofa trusted third party, comprising one or more server units at one ormore geographic sites).

BRIEF DESCRIPTION OF THE DRAWINGS

To assist understanding of embodiments of the present disclosure and toshow how such embodiments may be put into effect, reference is made, byway of example only, to the accompanying drawings in which:

FIG. 1 is a schematic block diagram of a system for implementing ablockchain,

FIG. 2 schematically illustrates some examples of transactions which maybe recorded in a blockchain,

FIG. 3 schematically illustrates a challenge and response of a PUF,

FIG. 4 is a schematic block diagram of a system comprising a PUF,

FIG. 5A is a schematic block diagram of an expanded PUF in accordancewith embodiments disclosed herein,

FIG. 5B is a schematic block diagram of the expanded PUF in anon-expanded mode of operation,

FIG. 6 is a schematic illustration of a system involving a trusted thirdparty or publication medium in the distribution of challenge-responsepairs, and

FIG. 7 is a schematic flow chart of a verification process in accordancewith embodiments disclosed herein,

FIGS. 8A-C schematically illustrate methods of generating a set ofchallenges from a master challenge in accordance with embodimentsdisclosed herein, and

FIG. 9 schematically illustrates a method of recording response data onchain.

DETAILED DESCRIPTION OF EMBODIMENTS

The robustness of systems such as key-generation systems andprivacy-preserving identity systems for both humans and machines may beimproved by the involvement of physically unclonable functions (PUFs).These may be parties and/or autonomous machines that are interactingwith one another, or with a public system such as the blockchain.

These functions, which are based on physical systems and secured by theassumption of random, undeterminable and non-repeatable variations inthe manufacturing of physical devices, can be used to fortify a linkestablished between a human identity and their device, or furthermore toestablish an unforgeable unique identity for a device itself.

In the literature, PUFs are categorised into weak and strong types,categorised by their distinct properties. According to one aspect below,there is provided a generalised extended PUF (ePUF) framework fordescribing a practical PUF device that has the benefits of both of thesetypes of PUF; namely that an ePUF may produce a large range ofchallenge-response pairs to be used in applications, while remainingpractical and cost-efficient to implement.

More generally various aspects relating to PUFs and the management ofchallenge-response pairs are disclosed herein. These different aspectsmay be used individually or in any combination. These include forexample:

-   -   I. an expanded PUF for expanding the challenge-response space of        a PUF;    -   II. a set of blockchain-agnostic protocols for establishing        human and/or device identity by using ePUF devices;    -   III. a framework for improving these identity protocols by        leveraging the blockchain;    -   IV. a technique for lightweight storage of challenge-response        pairs; and    -   V. a set of novel applications of ePUF devices to a variety of        problems, such as the implementation of KYC for simplified        payment verification (SPV) processes, and for verifiable        computation by devices.

1. PHYSICALLY UNCLONABLE FUNCTIONS (PUFS)—PRELIMINARIES

The term physically unclonable functions (PUFs) refers to a class ofphysical systems and devices which act as general-purpose randomfunctions. These PUFs are uniquely characterised by their physicalproperties, often at the sub-micron scale, which means each can beuniquely identified and verified by probing those properties withphysical stimuli. At a high level, one can consider PUFs as functionsthat map challenges to responses; pairs of which are often referred toas challenge-response pairs (CRPs). One can use the following notationto describe such a map F as:

F: C→R∀(C,R)∈Φ_(F),

where C, R denote challenges and responses respectively, and Φ_(F) isthe set of all challenge-response pairs of the form (C, R) that can beproduced by the PUF.

The unique physical properties of a PUF are typically the result ofrandom process variations inherent in the manufacturing of physicaldevices, such as silicon chips. Assumptions typically made about PUFsare that:

-   -   1. it is intractable to completely determine the parameters of        the physical system by any form of analysis; and    -   2. the parameters of the physical system are not known by any        party, including the original manufacturer of the device that is        used as a PUF. This assumption if often referred to as        manufacturer-resistance.

These assumptions allow a PUF to be used to produce unpredictable yetdeterministic responses to arbitrary challenges. This challenge-responseprocess treats a PUF like a physical black box, as illustrated in FIG. 3.

FIG. 3 shows a PUF 302 modelled as a physical black box. A submittingparty 103S submits a challenge C as an input to the PUF 302, and inresponse the PUF 302 generates a corresponding response R. Thesubmitting party submits the challenge from a device such as a computerdevice (not shown) of the submitting party, which could be the same or adifferent device as that in which the PUF 302 itself is implemented.

The submitting party 103S could be a party generating challenge-response(CR) pairs as part of a set-up phase (examples discussed later) toestablish a set of expected responses linked to the identity of a targetparty or device. Or the submitting party 103S could be a verifying partysubmitting a challenge in a later verification phase in order to verifythat the generated response matches an expected response, thus verifyingthe identity of a target device comprising the PUF 302 or a target partyin possession of the PUF.

In another example scenario, the submitting party 103S may be a partywho wishes to use the generated response as a key, or a seed to generatea key, for use in a cryptographic application such as a blockchainapplication (e.g. to sign a blockchain transaction).

FIG. 4 shows a system comprising an example of an interface to a PUF302. The system comprises a processor 402 and the PUF 302. The interfacecomprises interface logic 404, which is stored in memory and arranged torun on the processor 402. The memory on which the interface logic 404 isstored may comprise one or more memory units employing one or morestorage media (e.g. magnetic medium such as magnetic disk or tape, or anelectronic medium such as ROM, EPROM, EEPORM, flash memory, SRAM, DRAM,etc.). The processor 402 may comprise one or more processing units (e.g.a general purpose processor such as a CPU, or an application specific oraccelerator processor such as a GPU, DSP or crypto-processor). It isalso not excluded that the interface logic 404 could instead beimplemented partially or wholly in dedicated hardware circuitry, orconfigurable or reconfigurable circuitry such as a PGA or FPGA.

The submitting party 103S uses a device (not shown) to submit achallenge C to the PUF 302 via the interface logic 404. The device usedby the submitting party 103S could for example be a computer device,either an external computer device or the same computer device on whichthe processor 402 is implemented. The PUF 302 then returns thecorresponding response R back to the device of the submitting party 302via the interface logic 404. In some embodiments, discussed in moredetail later, the interface logic 404 may comprise access control logic406 which restricts access to the PUF 302 to only certain parties, e.g.those that can present recognized credentials such as a password, PIN orbiometric information. And/or, a physical interface to the devicecomprising the processor 402 may be restricted, such as by being locatedin a room or complex to which only authorized personnel have access, orbeing kept in a locked box or cabinet. In alternative systems however,the interface logic 404 could be made available for any party to querywith challenges.

The challenge-response process of a PUF allows the generation ofpseudo-random data values by extracting these challenges from chosenresponses. For example, PUFs can be used as key-generators to extractrandom repeatable data to be used in cryptography. Note that the PUF 302acts in a deterministic and repeatable way, such that a PUF will yieldan identical response when given the same challenge on multiple separateoccasions.

There are a number of different physical systems that can be used asPUFs, and there are many different implementations of PUFs using thesesystems. An illustrative example of a PUF is an optical medium thatcontains bubbles, which, when probed by a laser, produces a responsediffraction or ‘speckle’ pattern that is deterministically determined by(i) the position of the laser, and (ii) the small-scale parameters ofthe optical medium.

1.1. Classes of PUFs

1.1.1 Weak PUF: Weak PUFs are characterised by having a smallchallenge-response space, and many have only a single challenge suchthat the size of the CRP space is |Φ_(F)|=1. In general, thechallenge-response space for a weak PUF is considered to be of the orderO(n), where n is the number of components in the PUF that are subject touncontrollable manufacturing variations.

In the case of weak PUFs, it is typically also assumed that access tothe responses of the PUF is restricted. This is because, due to thesmall number of CRPs serviced by the weak PUF, an adversary mayenumerate all such pairs in a reasonable time and may therefore emulateor ‘spoof’ the behaviour of the PUF. This restriction is sometimesreferred to as a restricted challenge-response interface when discussingthe behaviour of weak PUFs.

These properties make weak PUFs most naturally suited to use incryptographic applications as a key-generator, where the one (or few)CRP(s) generated by the PUF may be used as a secret key forcryptographic operations, such as for encrypting on-device non-volatilememory (NVM) or for use as an HMAC symmetric key. In such cases, the keyderived from the response of the PUF must be kept secret and known onlyto the possessor of the device for both the security of thecryptographic processes performed and also of the PUF itself.

A prominent and widely-implemented example of a weak PUF is the SRAMPUF, where the term ‘SRAM’ refers to ‘static random-access memory’. Thedesign of the SRAM PUF leverages variations in the ‘powered-on’ state ofSRAM chips, which each have a unique fingerprint owing to variations inwhich SRAM cells in the chip are in ‘0’ or ‘1’ states when the chip ispowered-on.

In this case, the PUF construction is considered weak because there isone fixed mode to probe the PUF (i.e. by powering on the SRAM chip), andthus only a single CRP. In this case, the one and only ‘challenge’ is tosupply the SRAM chip with power, and the response is the uniquefingerprint derived from its powered-on state. Access-control, to ensurethe secrecy of the response, can also be implemented using the existingmemory access-control policy or mechanism in place on the device inwhich the SRAM PUF is used, or alternative mechanisms employed on thedevice.

A feature of some PUF implementations, such as in the case of the SRAMPUF, is the use of error-correction in the responses generated by PUFsto ensure the same challenge will yield the same response in acondition- and time-invariant manner. Details of such error-correctiontechniques are known to a person skilled in the art. In some cases, theerror-correction process may require that PUF devices are ‘enrolled’initially, to provide a source of helper data which is combined with aresponse later generated on demand to facilitate the error correction.

1.1.2. Strong PUFs: by contrast to weak PUFs, strong PUFs arecharacterised by having a large space of possible challenge-responsepairs (CR-pairs, or CRPs) that can be utilised. This large space of CRPsmeans that it is considered infeasible for an adversary to enumerate allof the challenge-response pairs within the domain of a strong PUF inpolynomial time. This property means that strong PUFs may have anunprotected challenge-response interface in general, since the abilityfor an adversary to freely access the PUF will not compromise itssecurity by allowing an enumeration and spoofing of the PUF, as would bethe case for weak PUFs. This class of PUFs is also said to produceunpredictable responses, even from the perspective of an adversary whoknows a large subset of CDF, meaning that strong PUFs act more like acryptographic hash function with a large domain.

However, there is a restriction placed on strong PUFs that only theresponse R should be given by the PUF when presented with a challenge C,and no other information about the internal working or operation of thePUF should be leaked in the process. This restriction is to mitigatevarious analytical attacks whereby an adversary may try to characterisethe physical system underpinning the behaviour of the PUF. These areoften referred to as modelling attacks in the literature.

Similarly to weak PUFs, some strong PUF constructions may rely on errorcorrection techniques to ensure the accuracy of responses generated bythe devices.

The main existing applications of strong PUFs are to facilitate systemauthentication and identification using the inherent challenge-responsemechanism. These mechanisms rely on protocols that involve the creationof CRPs as shared secrets directly between two parties, and oftenrequire at least one party to generate a table of CRPs ahead of time (aninitial set-up) to be used as authentication tokens for the other party.

One of the earliest examples of a strong PUF implementation was theoptical PUF system. In this construction, the PUF comprises an opticalmedium that contains randomly-distributed physical imperfections, as aresult of manufacturing variations, which scatter incident light.

This PUF construction is able to be probed by a laser beam directed atthe optical scattering medium. In this case, the direction andpolarization of the incident beam form the challenge, and the scatteringpattern observed is taken as the PUF response.

However, this strong PUF construction is complex to implement, due tothe fact that the measuring device is separate from the rest of the PUFdevice and is also difficult to integrate directly with semiconductorcomponents. This is in addition to costs associated with the apparatusitself, and the lack of portability of the arrangement reducing itsutility for everyday applications.

An electrical integrated strong PUF, known as the arbiter PUF (APUF),has since been proposed, which overcomes some of these issues. Thisconstruction utilises signal multiplexing and leverages runtime delaysin electrical components. Many other strong PUF constructions have beenproposed in parallel, although many lack practical suitability forwidespread use, and many have associated weakness regarding security andpotential attack vectors. For example, a highly problematic potentialattack is the man-in-the-middle attack, whereby an attacker canintercept challenges submitted in the clear and spoof certifiedcomputations.

1.1.3. Controlled PUFs: a third class of PUFs, known as a controlled PUF(CPUF), improves on existing strong PUF constructions, but using them asa building block. These PUFs take a strong PUF and apply an additionalcontrol logic that restricts access to the PUF, which distinguishes themfrom non-controlled strong PUFs which otherwise may have unprotectedchallenge-response interfaces.

As shown in FIG. 4 , the control logic 406 applied to the PUF, which isnow part of a larger PUF device, may mediate access to the PUF 302itself. This means that the control logic component 406 can restrictwhich challenges are presented to the PUF, as well as controlling howthe subsequent responses are revealed to the user.

In CPUF construction, preferably the control logic component 406 shouldbe embedded within or enveloped by the strong PUF component. Accordingto one definition of a CPUF, a PUF is said to be controlled if can onlybe accessed via an algorithm that is physically linked to the PUF in aninseparable way (i.e. an attempt to circumvent the algorithm will leadto the destruction of the PUF). This embedding should make the probingof the control logic considerably more difficult.

This will establish a mutually-beneficial relationship between the PUFcomponent and the control logic component, such that each mitigates atype of attack on the other. Namely, the encapsulation of the controllogic within the PUF device itself protects the control logic fromphysical or invasive attacks because this would irreparably damage thePUF component and alter its responses, while the control logic naturallyprotects the PUF component from protocol-level attacks to extract CRPsor other information about the internal physical system underlying thePUF itself.

The applications of CPUFs are much the same as strong PUFs, but can beachieved in a more robust manner. In particular, certified computationsand proof of execution can be achieved easily with the protocolsoutlined above.

An early example of a CPUF, which extended the design of the strongarbiter PUF (APUF), required a control logic to be intertwined with theAPUF itself in the manner already described, such that the control logicand APUF mutually protect one another from different types of attack.The controlled APUF design generates a large set of CRPs from a singlestatic response from an integrated circuit (IC) by incorporating thetransient response of the system.

Another known example of a controlled PUF is a PUF-FSM construction.This comprises a strong PUF (an APUF in reality) in conjunction with afinite state machine (FSM) that acts as the control logic that restrictsaccess to the challenge-response interface of the APUF component itself.

1.2. Discussion

1.2.1. Practicality: it is acknowledged in the literature that toproduce strong PUFs that are both practical and lightweight, whilst alsobeing integrable with standard complementary metal-oxide semiconductor(CMOS) components, is highly challenging. By contrast, weak PUFs such asthe SRAM PUF are inexpensive to produce and can be trivially combinedwith integrated circuit architectures.

1.2.2. Attacks on PUFs: there are a number of different attacks thathave been proposed and studied, where different attacks may targetspecific PUF constructions or classes. Some of the most widely-knownattack types are listed as follows.

-   -   MITM attacks—these attacks target PUFs uncontrolled strong PUFs,        where an adversary may intercept challenges made in the clear to        impersonate or spoof the response of a PUF, particularly when        used for certified computation.    -   Modelling attacks—these attacks have proven a vulnerability for        many strong PUF constructions, such as the APUF.    -   Chosen challenge attacks—these attacks also affect strong PUFs        and are partly the motivation for moving towards CPUF        architectures.

There are also other issues with various PUF designs, such as lack ofuniqueness in some cases, which have let to exploits that undermine thesecurity of the PUF system in question.

1.2.3 Security models: the security models of PUF constructions tend toshare some similarities, such as the assumption that the random processor manufacturing variations from which their CRPs arise ismanufacturer-resistant and that it is intractable to characterise thephysical system of the PUF by analytical means. However, there are alsosome differences in the security models for the three main PUF classes.

-   -   Weak PUFs—the security of a weak PUF relies on the assumption        that its CRPs are kept secret, otherwise the device can be        enumerated and impersonated. This means that a weak PUF can be        used to provide a source of entropy and secure storage of that        entropy for cryptographic operations, but the actual CRP        response data itself is not revealed publicly in the process.    -   Strong PUFs—the security of a strong PUF is dependent on the        fact that its CRP space tends to be exponential in the number of        challenge bits, and thus the enumeration of the entire space is        infeasible in a reasonable timeframe. This means that the CRP        responses of a strong PUF can be revealed by the device, unlike        in the case of weak PUFs.    -   Controlled PUFs—the security of a controlled PUF is determined        by the combination of control logic, which protects from        protocol level attacks, and the PUF itself, which protects from        physical attacks.

Two properties of strong PUFs, which differentiate them from weak PUFs,are as follows. Firstly, a strong PUF has a large set of CRPs. Thismeans that a strong PUF has a large challenge space Φ_(F), where a weakPUF has typically only one (or few) challenge(s) available to it. Astrong PUF is moreover considered unpredictable with respect to any andall known CRPs. In other words, knowledge of an arbitrary number of CRPsgives no advantage in predicting the response of a new challenge.

Secondly, a strong PUF can have an unprotected challenge-responseinterface. The assumption is made that a given strong PUF does notrequire access-control logic to restrict access to thechallenge-response interface. This means that any party with physicalaccess to the PUF may apply challenges, and obtain responses,arbitrarily, without revealing any additional information about the PUFor its physical properties.

A controlled PUF has a protected challenge-response interface but also alarge challenge-response space like a strong PUF.

2. EXPANDED PUF (ePUF)

The following discloses a system and method for expanding thechallenge-response (CR) space of a PUF, by generating multiple secondaryCR pairs from a given CR pair of the base PUF 302. This may be referredto herein as an “expanded PUF”, or “ePUF”. The idea could be used forexample to expand the challenge-response space of a weak PUF with onlyone or a limited number of inherent CR pairs, without the complexity orimpracticality of a typical strong PUF mechanism (such as an optical PUFrequiring a laser, optical medium and sensor). However, in principle thedisclosed techniques could be used more generally to expand the numberof CR pairs of any base PUF, whether weak, strong, controlled orotherwise; or to transform a CR pair of any PUF for other purposes, suchas obfuscation or re-usability.

FIG. 5A shows an expanded PUF (ePUF) 500 in accordance with embodimentsdisclosed herein. The ePUF 500 comprises a constituent base PUF 302,which could for example be a conventional weak PUF. The ePUF 500 furthercomprises a transform function 502, e.g. a hash function such as acryptographic hash function (for instance SHA256, etc.). The ePUF 500also comprises interface logic 404′, which may be similar to theinterface logic 404 discussed in relation to FIG. 4 , but withadditional interfacing functionality. The interface logic 404′ andtransform function 502 may be implemented in software, e.g. embeddedfirmware, which is stored in memory and arranged to run on a processor402 (such as shown in FIG. 4 , but running the additional functionalityof the interface 404′ and transform function 502). The memory on whichthe interface function 404′ and transform logic 504 are stored maycomprise one or more memory units employing one or more storage media(e.g. magnetic medium such as magnetic disk or tape, or an electronicmedium such as ROM, EPROM, EEPORM, flash memory, SRAM, DRAM, fuselatches, etc.).

The processor on which they are run may comprise one or more processingunits (e.g. a general purpose processor such as a CPU, or an applicationspecific or accelerator processor such as a GPU, DSP orcrypto-processor). It is also not excluded that the interface logic 404′and/or transform function 502 could instead be implemented partially orwholly in dedicated hardware circuitry, or configurable orreconfigurable circuitry such as a PGA or FPGA.

The interface logic 404′ is operatively coupled to the transformfunction 502 and optionally also to the base PUF 302. The base PUF 302is operatively coupled to the transform function. The interface logic404′ is arranged to receive in input from, and provide an output to, adevice of a submitting party 103S (not shown in FIG. 5A), e.g. acomputer device, which could be the same device that the ePUF 500 isimplemented on or an external device. The submitting party 103S could bea party using the ePUF 500 to perform a set up, to generate a set ofchallenges and expected responses to be linked to an identity for futurereference; or could be a verifying party using the PUF at a later timeto verify whether the generated response matches apreviously-established expected response (or a challengee generating theresponse to provide to a verifying party). In another exampleapplication, the submitting party 103S could be using the ePUF 500 toproduce a response for use as a key, or as a seed for generating a key.E.g. this could be used as a cryptographic key to encrypt or sign amessage, e.g. to sign a part of a blockchain transaction.

The base PUF 302 is operable to generate a “primary” response Rw as anoutput, corresponding to receiving a “primary” challenge Cw as an input.The “primary” challenge-response (CR) pair herein refers to a base or“native” (i.e. inherent) CR pair of the base, constituent PUF 302. Insome embodiments, the base PUF 302 may be capable of generating only asingle base (i.e. primary) response Cw in response to a single challengeCw, like a weak PUF.

In operation, the interface logic 404′ receives challenge data (achallenge input) comprising at least a “secondary” challenge Ci from thedevice of the submitting party 103S. In addition, the primary (base)challenge Cw is input to the base PUF 302 in order to generate theprimary (base) response Rw. In embodiments the submitting party 103S isrequired to include the base challenge Cw in the challenge data input tothe ePUF 500, and the interface logic 404′ routes this to the base PUF302 in order to generate the primary response Rw. However, it is notexcluded in other embodiments that the primary challenge Cw is input tothe base PUF 302 from an internal source such as a memory, fuse latchesor dedicated circuitry. Either way, the transform function 502 isarranged to receive as inputs: a) the secondary challenge Ci as receivedin the input challenge data from the submitting party, and b) theprimary response Rw as generated by the base PUF 302. The transformfunction 502 is a function configured to map a combination of these,deterministically, onto a unique respective “secondary” response Ricorresponding to the particular combination of Ci and Rw input to thetransform function 502. The secondary challenge response pairs may bereferred to herein as “secondary” in the sense that they are layered ontop of the primary (base) CR pair, being generated in part based on theprimary response Rw. They could also be called the “expanded layer” or“supplementary” challenges and responses.

In embodiments, the transform function 502 comprises a hash function,e.g. a cryptographic hash function such as a SHA or DSA hash function.There are at least two different ways a hash function can be used. Inthe first, the transform function 502 comprises a hash of a preimage,wherein the preimage comprises a combination (e.g. concatenation) of thereceived secondary challenge Ci and the generated primary response. I.e.Ri=H(Ci∥Rw). Or more generally the preimage could comprise otherelements as well, and/or another form of combination other thanconcatenation.

In the second, alternative approach, the transform function 502comprises a hash of a preimage wherein the preimage comprises thereceived secondary challenge and the hash function is initialized withthe generated primary response. I.e. Ri=H(Ci) where H is initialized byRw. Or again more generally the primage of H could comprise otherelements as well, as long as it comprises at least Ci. Being initializedby Rw means that the mapping itself, of preimages to outputs defined bythe hash function H, will depend on the Rw. Whereas in the previouscase, the mapping of preimages to outputs caused by H does not depend onRw, rather the preimage depends on Rw. I.e. in the previous paragraph,the preimage depends on Rw, and in this paragraph only H depends on Rw.

More generally still, in principle any function can be used as along asit deterministically and uniquely maps a combination of Ci and Rw onto arespective value of Ri, for each possible Ci in the domain to beaccommodated by the ePUF 500.

The secondary challenge Ci can take any of a number of differentpossible values, and the transform function 502 will map them torespective values of the secondary response Ri based on the value of theparticular received secondary challenge Ci and the value of the primaryresponse Rw. Hence the ePUF 502 is capable of expanding the CR space ofa given primary (base) CR pair to multiple secondary CR pairs. Inembodiments Ci can take any arbitrary value within the range of valuessupported by the variable used (e.g. if it is a 32 bit integer it cantake any of 2{circumflex over ( )}32 values).

In some embodiments, the ePUF 500 may be capable of operating in analternative mode of operation, as shown in FIG. 5B. In this case, theinterface logic 404′ detects that the input challenge data comprisesonly the primary challengee Cw. In response it routes the received valueof Cw to the base PUF 302, and routes the resulting primary response Rwback to the device of the submitting party 103S. In other words in thisembodiment, the ePUF 500 is also capable of operating in a “legacy” or“non-expanded” mode.

Optionally, depending on the application, the interface logic 404′ maycomprise access control logic 406 which restricts access to only alimited number of possible submitting parties 103S, such as by onlygranting access to a party that is able to present credentials (e.g.password, PIN or a biometric input) which it recognizes as being mappedto an authorized party. In this case the ePUF 500 could be considered asa form of CPUF. Alternatively the physical interface to the ePUF 500could be legally or physically protected, such as by keeping the devicecomprising the ePUF 500 in a room or premises to which only a limitedset of parties is permitted access, or keeping it in a locked box,cabinet or room. In this case the ePUF 500 could be considered like akind of expanded weak PUF.

Alternatively or additionally to such physical restrictions on theinterface to the PUF, access may also be restricted by restrictingaccess to the primary challenge. E.g. the target party 103T (“Alice”,discussed later) may be the only party who knows Cw.

As another alternative however, access to the interface logic 404′ maynot be restricted, e.g. any party may be free to query it via theInternet. In this case the ePUF 500 could be considered like a kind ofstrong PUF 502 created by expanding a weak base PUF mechanism.

The arrangement shown in FIG. 5A provides a new hybrid class of PUFdevice referred to herein as an expanded PUF (ePUF), which may be usedgenerally as a framework for a number of applications, such as presentedlater.

An ePUF may be defined as a physical device or system, as shown in FIG.5A, comprising the following three modules in conjunction: a base PUF302 such as an inherently weak PUF; a transform function 502 such as acryptographic hash function; and an interface logic module 404′. Asdiscussed, an ePUF 500 may be ‘expanded’ relative to a regular PUF 302by introducing a transform function 404′ such as a cryptographic hashfunction, because it increases the size of the unique challenge spaceΦ_(F) from |Φ_(F)|˜1 for the base weak PUF 302 to |Φ_(F)|>>1 that isbounded instead by the choice of hash function, rather than the physicalsystem of the weak PUF.

The idea of realising a system that combines the large CRP space of astrong PUF with the practicability of a weak PUF, per se, has beenexplored previously. It is known to use multiple FPGA-based weak PUFs incombined operation to produce a system with the character of a strongPUF. The intention here is partly to ‘expand’ the CRP space of the baseweak PUFs. However, the existing constructions of this nature arelimited in practice. In the case of the FPGA design mentioned above, thesystem must be built on an FPGA and is still subject to a relatively lowCRP space (˜2¹⁰).

The ePUF design disclosed herein is designed to be extremelylight-weight, in that it only requires the addition of an interfacelogic component 404′ and a cryptographic hash function (or other suchtransform function) 502 to an existing weak PUF 302. For instance, if anSRAM PUF is chosen as a widely-used weak PUF 302, then the addition ofthe two remaining modules 404′, 502 should not produce significantoverhead, e.g. being implemented as a small algorithm in software (e.g.firmware) or a relatively simple piece of hardware circuitry. Moreover,the space of possible outputs of the ePUF 500 is expanded to the rangeof the chosen hash or transform function 502, which is considerablylarger than the above. For instance, if the SHA-256 hash function ischosen, the space of possible outputs (and therefore CRPs) is increasedto 2²⁵⁶−1 immediately, and there is no need to scale the hardwareoverhead farther than embedding the hash function module itself.

FIG. 5A shows the schematic design for an expanded PUF (ePUF) 500. Theembodiments where a cryptographic hash function is used also mean thatan ePUF 500 has the property that its CRPs are unpredictable, which isalso the case for strong PUF systems.

The control logic element 406 of the ePUF device may also be generalisedin this construction. The control logic 406 may be implemented simply asphysical security, similar to an SRAM PUF, if this is appropriate to theapplication, for example.

Alternatively, the control logic module 406 may be implemented as asoftware control module similar to that used with CPUFs, where it is infact embedded within the PUF device itself to provide the mutualsecurity benefits of encapsulation discussed previously. However, apoint here that differentiates the ePUF design from that of CPUFs inparticular is that there is no strict requirement for the control logicto be implemented this way.

It need not necessarily be assumed that an invasive attack on thecontrol module 406 necessarily alters the behaviour of the weak PUFcomponent 302 in the ePUF design. Instead, the implementation of thiselement may be chosen on a case-by-case basis.

2.1. Challenges and Responses for ePUFs

The set of challenge-response pairs (C, R)∈Φ_(F) corresponding to anePUF may be defined in the following way:

Φ_(F) = {(C_(w), R_(w)), (C₁, R₁), (C₂, R₂), …, (C_(N), R_(N))},F : C_(i) → R_(i), ∀i ∈ (1, N) F_(w) : C_(w) → R_(w)

where (C_(w), R_(w)) is a privileged CRP corresponding to the basechallenge-and-response of the weak PUF 302 and where the map F_(w) isdefined by the unique physical properties of the weak PUF. The pair(C_(w), R_(w)) may be referred to as the base or primary pair of theePUF herein. The map F conversely is defined by the cryptographic hashfunction chosen for the ePUF. FIGS. 5A-B show extracting responses froman ePUF 500 where (FIG. 5B) the challenge is only Cw and (FIG. 5A) thechallenge also comprises Ci.

In some embodiments of an expanded PUF, all challenges C_(i), i∈{1, 2, .. . , N} must be accompanied by the base challenge C_(w), and the baseresponse R_(w) is incorporated in the process for generating all otherresponses R_(i), as shown in FIG. 5A.

The process depicted in FIG. 5A for generating generic CRPs using anePUF is designed to use the base challenge-response pair (C_(w), R_(w))by expanding this base secret pairing by applying it to any otherarbitrary challenge C_(i). The algorithm used to generate CRPs from anePUF may be tailored to a specific use, provided that the it makes useof the base pair (C_(w), R_(w)) in a deterministic way. A simple exampleof such an algorithm, denoted getResponse( ), can be written as follows.getResponse( ):

  Inputs: Challenge  1. Obtain challenge from user/client.  2. Checkchallenge = = C_(w)?   i. If yes:    1. Probe weak PUF module with C_(w)to obtain R_(w)    2. Set Response ← R_(w)   ii. If no:    1. SeparateChallenge into C_(w) and C_(i) components.    2. Probe weak PUF modulewith C_(w) to obtain R_(w)    3. Send C_(i) and R_(w) to hash functionmodule.    4. Compute hash(C_(i), R_(w), H)    5. Set Response ←hash(C_(i), R_(w), H)  3. Return Response  Outputs: Response

The function hash(C_(i), R_(w), H) is a generic function that is used tocompute a hash digest, using the cryptographic hash function H. Thefunction hash( ) may be implemented in a number of ways, such as bysimply computing H(C_(i)∥R_(w)) in a simple case, or it could beimplemented by taxing computing H(C_(i))_(R) _(w) where the value R_(w)has been used as the initial vector of the hash function H. Either way,the output of hash( ) depends on both C_(i) and R_(w).

The diagrams in FIGS. 5A and 5B show that an ePUF 500 may be equippedwith interface logic 404′, optionally comprising a control logic module406. In embodiments there are two possible paths to take in generating aresponse, where the path of FIG. 5B is used when the challenge is simplyC_(w), and the path of FIG. 5A is used when the challenge is a new valueC_(i) that is accompanied by C_(w). This is deterministic.

The disclosed ePUF design may be used to provide any of the followingadvantages and/or others.

-   -   A large CRP space, defined by the domain and range of the chosen        hash function.    -   Flexibility to separate control logic from the PUF itself.    -   The security primitives of a weak PUF.

This means that a user can use an ePUF device analogously to a CPUFdevice, but where the controlled access to the PUF includes both (I)securely storing the base CRP of the weak PUF (C_(w), R_(w)), and (II)restricting physical access to the PUF device to the intended user only.In this model, the base pair (C_(w), R_(w)) acts like a master key fromwhich an extremely large number of other CRPs of the form (C_(i), R_(i))may be derived, and where C_(i) may be submitted by an external or thirdparty.

2.2. Applications of an ePUF

The possible applications (use cases) of an ePUF device can beclassified broadly into at least two main categories:

-   -   1. Linking identity to activities or computational operations;        and    -   2. Acting as a key-generator for cryptographic operations.

Application (1) is most commonly implemented by existing strong PUFs,and (2) is most commonly by existing weak PUFs. The fact that the ePUFconstruction combines the properties of each means the ePUF may betreated as equally suited to either application. In application (1), anadvantage is that one may implement such applications far more easily inpractice using an ePUF generally than most strong or controlled PUFs.

3. IDENTITY LINKAGE SYSTEM

In this section, there is disclosed a generic framework for linkingeither human or machine identities to PUF devices.

Embodiments may use an expanded PUF (ePUF). The intention here is toformulate a PUF architecture that provides for a robust, yet highlygeneralised and flexible identity system, which can be repurposed formany different use cases. The properties we aim to capture in thisconstruction are:

-   -   A large CRP space comparable to that of a strong PUF;    -   A practicality comparable to that of a weak PUF; and    -   A control logic that is more flexible than that of a CPUF.

The ePUF design may be used as the basis model for a PUF used in a rangeof identity-establishment protocols. Embodiments may allow forindependence of the end user or machine in the process. Where existingschemes, which may also be repurposed to use an ePUF, rely on a trustedthird party to directly access the PUF device during setup, ePUF-basedproposed systems may allow the end user of a PUF device to insteadestablish an identity and participate in onward authentications withoutthe need for the third party to access the device locally or directlyduring setup.

Some implementations may improve the robustness of and extend furtherthese identity-linkage protocols by introducing a public blockchain. Twoconcepts that may be employed here are (A) the use of the blockchain asa tamper-proof CRP-management system, and (B) the use of a blockchainnetwork as a time-stamping service for mediating request-responsemessages used in the identity-linkage protocols, and providing anefficient revocation system.

FIG. 6 shows an example system for identity linkage and verification inaccordance with embodiments disclosed herein. FIG. 7 shows acorresponding method.

The system comprises a PUF module 603, computer equipment 102T of atarget party 103T, and a response data store 601. The PUF module 603comprises an ePUF 500 as described previously in relation to FIGS. 5Aand 5B, or alternatively it may just comprise a conventional PUF 302 orPUF plus conventional interface logic 404 as described previously inrelation to FIGS. 3 and 4 . The response data store 601 could be part ofthird-party computer equipment 602 and administered by a trusted thirdparty, or could instead be a distributed peer-to-peer storage mediumsuch as a blockchain. The third party equipment 602 may for examplecomprise server equipment comprising one or more server units located atone or more geographic sites (cloud storage techniques are in themselvesknown in the art). The system may further comprise computer equipment102V of a verifying party 103V, or in some alternative cases theverifying party may interact directly with the PUF module 603, targetparty's computer equipment 102T, or third party computer equipment 602.

Any reference herein to an action of a user or party 103, or suchlike—whether the verifying party 103V, target party 103T or a thirdparty—covers the possibility that the party is acting through computerequipment 102 of that party. For conciseness this will not necessarilybe stated explicitly each time, but it will be understood as implicitlycovered. This covers both the possibilities that either A) the action istriggered by or performed under control of a manual user input by theparty to the computer equipment, or B) the action is performedautomatically by the computer equipment on behalf of the party (sayingthat a party performs an action does not necessarily mean that a humanuser of that party manually instigates that action, but could insteadmean that the party's equipment performs that autonomously action onhis/her behalf). For avoidance of doubt, note also that a party mayrefer to a single individual person or a group or people ororganization, e.g. a company, a charity, a government body, or amunicipal or academic institution.

The computer equipment 102T of the target party 103T may be operativelyconnected to the response data store 601 (e.g. by a connection to thethird party equipment 602). The computer equipment 102V of the verifyingparty 103V may be operatively connected to the response data store 601(e.g. by a connection to the third party equipment 602). The computerequipment 102T of the target party 103T may be operatively connected tothe computer equipment 102V of the verifying party 103V. Any of theseconnections may be formed via one or more networks, e.g. one or morewide area networks such as the Internet or a mobile cellular network. Inembodiments any of these connections may be formed via a respectivesecure channel, e.g. established based on a shared secret shared betweenthe two parties in question. Wherever it is said herein that two partiescommunicate in any way, such as by sending a challenge or receiving backa response, etc., it will be understood that this covers the possibilitythat these communications may be performed via any suitable direct ornetwork connection between their respective computer equipment (102V,102T; 102T, 602; or 102V, 602). For the sake of conciseness this willnot necessarily be stated explicitly each time, but it will beunderstood as implicitly covered.

The target party 103T is a party whose identity is to be verified basedon the PUF module 603, or who owns or is otherwise responsible for orassociated with a device to be verified based on the PUF module 603. Theverifying party 103V is a party who is to perform the verification.There may be multiple verifying parties 103V (each of whom may actthrough respective computer equipment 102V), but for ease ofillustration only one is shown in FIG. 6 . The PUF module 603 may be inpossession of the target party 103T. It may be incorporated into his/hercomputer equipment 103T, or connected to it, e.g. as a peripheral or viaa local network, or a combination (e.g. the interface logic 404/404′could be implemented on the computer equipment 103T and the PUF 302could be an external peripheral). Alternatively the PUF module 603 maybe in the possession of the trusted third party. It may be incorporatedin or connected to the third party computer equipment 602, e.g. as aperipheral or via a local network, or a combination (e.g. the interfacelogic 404/404′ could be implemented on the third party equipment 602 andthe PUF 302 could be an external peripheral).

In general any of the target party 103T, verifying party 103V or thirdparty may take the role of the submitting party discussed previously inrelation to FIGS. 3, 4 and 5 . Any of the target party 103T, verifyingparty 103V or third party may take the role of the submitting party, ormay take the role of a setting-up party using the PUF module 603 toestablish a set of one or more CR pairs and link them to an identity ofthe target party 103T for use in a later verification phase. Somespecific example scenarios are discussed in more detail later.

The response data store 601 stores response data that was generated bythe PUF module 603 in a set-up phase. The data store 601 stores thisresponse data in association with evidence of an identity of a target,which may be the target party 103T or a device of the target party 103T.The verifying party 103V has access to the response data store 601 andcan use this to verify the identity of the target at a later time duringa verification phase. To do this the verifying party 103V challenges thetarget to produce a response Ri to a challenge Ci that was previouslyincluded in the set of challenges used in the set-up phase. If thetarget can produce the expected response according to what is stored inthe response data store 601, then this evidences that the target is inpossession or control of the PUF module 603, and thus may be assumed tobe the same party whose identity was captured in the set-up phase.

In an alternative variant, the response data store 601 may store one ormore public keys of one or more respective public-private key pairs thatwere generated based on the response(s) produced in the set-up phase,e.g. using the response as a seed. If the target later signs a message(e.g. a document or blockchain transaction) using one of the privatekeys, the verifying party can verify the signature using thecorresponding public key from the response data store 601. Note that insuch variants, the term “response data” is being used in a broader senseto cover data derived from the response Ri, not necessarily the explicitvalue or an attestation of the response Ri.

The response data store 601 may be publicly accessible, or access may berestricted to only a limited set of one or more parties including atleast one verifying party 103V. It may be hosted on a third party system602 or in a peer-to-peer manner, or alternatively it may be implementedin the computer equipment 102T of the target party 103T or the computerequipment 102V of the verifying party 103V.

Referring to FIG. 7 , the method comprises two phases: a set-up phase702 and a verification phase 704. In the set-up phase, at step 710 oneof the target party 103T or third party, acting as a setting-up party,submits a set of one or more challenges Ci (i=1 . . . n, where n>=1)into the PUF module 603. These are the secondary challenges in the casewhere an ePUF 500 is used. In the case where the target party 103T haspossession of the PUF module 603 and is performing the set-up, thechallenges Ci could be generated by the target party 103T or receivedfrom the third party system 602 or verifying party 103V. In the casewhere the third party has possession of the PUF module 603 and isperforming set-up, the challenges could be generated by the third partysystem 602 or received from the target party 103T or verifying party103V. Either way, in response the PUF module 603 generates acorresponding set of responses Ri based on the PUF 302/500. These arethe secondary responses in the case of an ePUF 500. There method thusgenerates a set of CR pairs {Ci, Ri}.

In embodiments, access to the PUF module 903 is restricted such thatonly the target party 103T (and the setting-party if a different party)can gain access to the responses Ri. This could be achieved by accesscontrol logic 404 or 404′ which may only grant access to a party who canpresent recognized credentials such as a password, PIN, biometric data,etc. And/or access to the physical interface to the PUF module 603 maybe physically protected, such as by keeping it in a locked container,cabinet or room; or it may be legally protected such as by storing thePUF module 603 in a room or complex to which only certain personnel arepermitted access. As another alternative or additional restriction, inthe case of an ePUF 501, knowledge of the primary challenge Cw may berestricted, such that only the target party 103T (and in embodiments atrusted third party acting as a separate setting-up party) knows Cw.

At step 720, the method comprises storing response data in the responsedata store 601. In embodiments the stored response data comprises arecord of the generated CR pairs {Ci, Ri}. The record of each CR paircomprises a record of the respective response Ri stored in a manner thatindicates the corresponding challenge Ci of the pair. In embodiments thestored record of each response Ri comprises an explicit value of theresponse, i.e. the actual value of Ri, explicitly disclosed to averifying party 103V who can read the records. The value could be storedin the clear or could be encrypted if the verifying party has thedecryption key to decrypt the value, but nonetheless the stored value isstill said to be the explicit value for the purposes herein in the sensethat it is explicitly disclosed to the verifying party 103V.Alternatively the record of the response could comprise an “attestation”of the response Ri, comprising a deterministic transform of Ri. Anexample would be to store the value of a hash H(Ri) or double hashH²(Ri). This enables the verifying party to check whether a value of theresponse R′i is the same as that recorded in the store by checkingwhether the same transform applied to R′i (e.g. H(R′i) or H2(R′i))matches the attestation. This has the benefit that the actual value ofthe response Ri is not disclosed. Therefore this variant of the methodcan be particularly useful where the store 601 is a public medium suchas a blockchain. However encryption would be another possibility.

Where the response data is stored in encrypted form, then each piece ofresponse data (e.g. each CR pair) may be encrypted individually, eachrequiring a different respective decryption key to decrypt.Alternatively subsets or the whole set of response data (e.g. all CRpairs for a given target party 103T) could be encrypted together, allbeing decryptable together as a group with the same key.

The response data, e.g. the CR pairs, are stored in the response datastore 601 in association with evidence of the identity of the target.For example the target party 103T may be required to produce one or morepieces of identification information, such as a passport, as part of theset-up. The evidence held in the response data store 601 in associationwith the response data could comprise a copy of this information itselfbeing stored explicitly in association with the response data (either inthe clear or in encrypted form accessible to the verifying party 103).Alternatively, if the response data store 601 is administered by atrusted third party or the verifying party 103V themselves, then themere fact of the response data being registered in the repose data store601 in association with a particular identity could be consideredsufficient evidence (the assumption being that the verifying party 103Vtrusts the setting-up party and the party administering the responsedata store 601, e.g. the trusted third party, to have suitably checkedthe target party's identification information upon set-up).

In the verification phase 704, at step 730 the verifying party 103Vaccesses the response data store to determine the response data to usein a verification operation. In embodiments, there are a plurality ofpotential verifying parties 103V, and each is allocated a differentrespective subset of one or more of the CR pairs. I.e. the response datastore 601 will only disclose, to a given verifying party 103V, theexpected response(s) Ri of the CR pair(s) allocated to that party. E.g.this scheme may be administered by the trusted third party system 602.Such a scheme advantageously keeps the CR pairs separate, such that oneverifying party 103V cannot pretend to another to be the target. Howeverif all the verifying parties 103V given access to the store 601 aretrusted then this is not essential.

In embodiments, the verifying party 103V does not initially know thechallenge that he/she is going to use, and determines this by accessingit from the data store 601 along with the corresponding response data(e.g. response or attestation). Alternatively the verifying party 103Vdoes know in advance which challenge he/she intends to use, and usesthis to look up which response data is mapped to this in the data store601.

In a scenario where the verifying party 103V (or indeed any party)accesses data from a blockchain, such as to determine the response dataand/or challenge, then accessing the blockchain may be performed eitherby directly querying a node of the blockchain network, or indirectly byquerying an intermediate service that caches blockchain data or mediatesqueries on behalf of parties seeking access to blockchain data. E.g. theverifier 103V could access the data from another service provider who isnot directly connected to the blockchain network 106, but might justgive the response-related data, and perhaps also a Merkle proof.

At step 740, the verifying party 103V submits a challenge Ci to thetarget party 103T, who is in possession or control of the PUF module603. This is a challenge corresponding to one of the records which theverifying party 103V accessed from the response data store 601 in step730. Note that in the scenarios where the trusted third party was inpossession of the PUF module 603 at set-up, the PUF module 603 may bephysically passed from the trusted third party to the target party 103Tbetween the set-up phase 702 and verification phase 704.

In response to the submitted challenge Ci, the PUF module 603 generatesthe corresponding response Ri, which the target party 103V returns tothe verifying party. At step 750 the verifying party checks whether thereceived response Ri is consistent with the response expected accordingto the response data that was accessed from the response data store 601at step 730.

As mentioned, the party performing the set-up steps 702 could be thetarget party 103T or a trusted third party who stores the response data(e.g. CR-pairs). In further variants, these steps could be performed byanother, coordinating party such as a trusted oracle (another thirdparty other than the party who, in embodiments, runs the third partycomputer equipment 602 comprising the data store 610). In suchembodiments the data store 601 could be the third-party system 602 (of adifferent third party) or a public peer-to-peer medium such as ablockchain. And/or in yet further variants, there could be provided aseparation between the party that performs the inputs to the PUF module603 and the party that receives the outputs.

As also mentioned, there are at least two possibilities for the mannerin which the response Ri is recorded in the response data store 601.This first is simply to explicitly store the actual value of Ri itself.In this case step 750 simply comprises comparing the stored value (whichwas established at set-up 702) with the value R′i (the purported valueof the response Ri) now received in response to the submitted challengeCi (in the verification phase 704). If they match, then the methodbranches to step 760 where the identity of the target party 103T isdeclared verified. Otherwise the method branches to step 770 where theidentity of the target party 103T is declared not verified.

The second possibility is that only an attestation of Ri is stored inthe response data store 601, e.g. a hash or double hash. In this case,the verifying party 103V applies the same transformation that was usedto generate the attestation to the response R′i that he/she receivedback from the target party 103T in the verification phase 704. If thismatches the stored attestation, then the method branches to step 760where the identity of the target party 103T is declared verified.Otherwise the method branches to step 770 where the identity of thetarget party 103T is declared not verified.

In the response data store 601, there are at least two possibilities forthe manner in which the corresponding challenge Ci is indicated as beingassociated with each recorded response Ri. The first is simply to storean explicit value of each CR pair {Ci, Ri}, i.e. to store the actualvalues of Ri and Ci (either in the clear or encrypted). Alternatively, asecond, more lightweight way, in accordance with embodiments disclosedherein, is to store a master challenge Cm from which the challenges Cican be derived according to a predetermined, deterministicchallenge-derivation function f.

This is illustrated in FIG. 8A. Each response Ri is stored inassociation with a respective index. The function f is either stored inthe response data store 601 or is pre-known to the verifying party 103V.Either way, the verifying party 103V inputs the master challenge Cm intothe function f to determine the challenge Ci corresponding to the indexi of at least one of the responses Ri. The verifying party 103V thenuses this challenge Ci to verify the target.

In some such embodiments, the function f may also be a function ofidentification information 806, which may be a single piece ofidentification information or a combination 804 (e.g. a concatenation)of a plurality of pieces of identification information 802 (e.g.passport info, mother's maiden name and fingerprint info). This maycomprise identification information of the target party 103T. Thisenables a set of challenges Ci specific to the particular target party103T, which is advantageous for security reasons as uniqueness may beimportant, for instance if the same third party system 602 is used togenerate challenge sets for different target parties. Using personalidentification information such as passport information or mother'smaiden name of the target party 103T is a good option since it issomething he/she already knows of has, and tends to keep private.

Alternatively or additionally, the identification information 806 maycomprise identification information of the verifying party 103V, suchthat f is a function of the identity of the particular verifying party103V. This could be used to allocate a particular subset of one or moreparticular challenges to a particular verifying party 103V, such thatdifferent verifying parties 103V are given different challenges Ci touse in the verification 704.

In some embodiments, regardless of how the master challenge Cm isformed, the challenges Ci may be mapped to the master challenge Cm in achained manner, such that the C1=f(Cm), C2=f(C1), etc., as shown in FIG.8B. In other words a first challenge C1 is determined by applying thefunction f to the master challenge Cm, and then the second challenge C2is determined by applying the same function f to the first challenge,and so forth. As an example, f may comprise a hash function.

In another variant, the challenges Ci may be mapped to the masterchallenge Cm in a hierarchical manner, as shown in FIG. 8C. This will bediscussed in more detail later.

The chained approach is more lightweight and also easier to recover fromthe root information if f( ) does not require any data other than theroot key. In the case of the hierarchical derivation, the indices in thetree would be added in, which would not be needed for a simple chainlike this: C_m, H(C_m), H(H(C_m)) . . . , e.g. where f( ) is just a hashfunction.

Regardless of the form of f( ), or whether the master challengecomprises identification information and/or other information, inembodiments the master challenge Cm may be received by the third partysystem 602 from the target party 103T during set-up 702. The third partythen stores the received master challenge in the data store 601 (e.g.either locally or on chain), for future use in verification 704.Alternatively the third party system 602 receives the set of challengesCi from the target party 103T, and derives the master challenge Cmtherefrom, e.g. by applying an inverse of the function f( ). In variantsof these approaches, the third party system 602 may receive theidentification information, master challenge or set of challenges fromelsewhere other than from the target party 103T, e.g. from an oracle orcoordinating party (not shown). A combination of such approaches couldalso be used (e.g. one piece of identification information beingreceived from the target party and one being obtained from elsewhere).Or in further alternatives, a third party is not involved and the targetparty 103T stores the master challenge on chain him/herself (or in someother peer-to-peer publication medium).

In further variants of the method of FIG. 7 , the response data storedin the response data store 601 may not comprise a record of the CRpair(s) generated at set-up. Instead, the response data may comprise apublic key of a public-private key pair, or a set of such public keys,wherein each of the one or more key pairs was generated based on arespective PUF response Ri from the set-up phase 702. E.g. the responseRi may be used as a seed in a public-private key-pair generationalgorithm. In such embodiments, the method proceeds as set out in FIG. 7, except that at step 730 the verifying party accesses one of the storedpublic keys, and at step 740 the verifying party 103V does not submit achallenge Ci to be input to the PUF module 603 of the target. Instead,the verifying 103V party obtains a message (e.g. document, file, or partof a blockchain transaction) that was (purportedly) signed by thetarget. This message could be sent to him/her by the target party 103T,or the verifying party 103V could access it autonomously from apublication medium such as a blockchain or website. Either way, at step750, the check comprises using the public key accessed from the store601 to verify the signature applied to the message (based on knownpublic-private key signature verification techniques which are, inthemselves, well known in the art).

The following now describes some example identity-establishment andverification protocols for ePUFs or PUFs more generally in accordancewith embodiments disclosed herein. Consider a prover Alice (target party103T) and verifier Bob (verifying party 103V).

There are at least three different challenge types in a PUF identitysystem. By way of example the below will be described in terms of anePUF, but more generally any PUF device could be used (any devicecomprising a PUF module 603).

-   -   1. Remote PUF challenge—The verifier challenges the prover        remotely, by requesting a response from Alice to a challenge        submitted by Bob. This mode assumes that the verifier knows an        expected response(s) from the prover's PUF, and also that the        PUF is possessed by the legitimate owner.    -   2. Local PUF challenge—The verifier challenges the prover        locally, by interacting with the PUF device controlled by Alice.        This mode assumes the verifier knows something about the        prover's identity, but nothing about the behaviour of their PUF.    -   3. Cryptographic challenge—The verifier challenges the prover to        satisfy some cryptographic requirement related to her identity,        such as by signing a message with a key that is provably linked        to a certified public key.

In the case of types 1 and 2, the challenge is explicitly dependent onthe PUF module 603 from both the prover and verifier's perspectives. Thechallenge, and thus the corresponding verification process, in thesecases is intrinsically linked to the operation of the PUF device (thedevice comprising the PUF module 603, e.g. Alice's computer equipment102T). In these cases, we are using the property of PUF devices thattheir physical state can be uniquely bound to an identity, and the PUFtherefore plays a central role in the identity system being utilised.

Note that the terms ‘remote’ and ‘local’ refer specifically to theinteraction between the verifier and the prover's PUF at the time ofmaking a challenge. This does not preclude a remote challenge protocolfrom having a setup phase that involves a local interaction between theprover and verifier ahead of time.

In case 3 however, the challenge and verification process need only berelated to a PUF device from the perspective of the prover. Theverification is not dependent on the verifier knowing whether or not aPUF has been used by the prover in generating the response to theirchallenge. In this case, the method is simply using the utility of a PUFas a key-generator for Alice, rather than for its utility in linkingidentity to the device itself.

In the following, example implementations are provided for the setup andverification, and optional update, and revocation processes, foridentity systems in each of the three modes of operation mentionedabove. In embodiments a generic trusted third party is involved in theprocesses relating to a PUF-based identity system. This is because suchidentity systems tend to require such a third party in order tomeaningfully assure integrity and trust in identity and relatedcredentials. In the case where an individual's identity is to beestablished and used in such a system, the trusted third party inquestion may be a certificate authority, government agent, or afinancial services provider such as a bank.

In the case where an identity is to be established for a machine ornon-human entity, the third party may be a device manufacturer, issuer,regulator, or some other relevant actor.

This case is particularly suited to an internet of things (IoT) orfurther a blockchain of things (BoT) paradigm, where identity is to beassigned to different members of a network of devices which may performtasks or calculations cooperatively to achieve some goal.

3.1. Remote PUF System

3.1.1. Setup: In the case of remote PUF challenges, assume that theverifier that submits a challenge C to the prover knows the expectedresponse R ahead of time. This means that the setup process in this casemust establish a set of CRPs (i.e. at least one) between Alice andanother party that can be used to derive a shared secret between themthat can be used to authenticate Alice's identity at a later time.

Assume that Alice establishes this shared secret with the generic thirdparty equipped to establish the identity, as mentioned previously, andthis third party may or may not be the verifying party that participatesin a verification process with Alice later. In the case where theverifying party is distinct from the identity-establishing third party,assume that the verifying party may obtain the relevant CRP informationused for the shared secret(s) from the third party.

There are two distinct options for the setup phase here, categorised bywhether Alice is the sole party with access to the PUF device at alltimes, or whether the trusted third party may also have access to thePUF device during setup phase only.

Case 1: Alice has sole access to PUF

-   -   1. The ePUF device is manufactured and distributed to Alice.    -   2. Alice applies to link her identity to her ePUF device by        contacting a trusted third party.        -   i. The third party establishes an identification account for            Alice, and requests proof of her identity.        -   ii. Alice supplies the third party with the relevant            identification documents or credentials.        -   iii. The third party verifies Alice's identity.    -   3. Alice and the third party establish a secure communication        channel for the rest of the setup process (e.g. via standard        Diffie-Hellman key exchange):        -   i. Alice and the third party exchange public keys P_(A),            P_(T) respectively.        -   ii. Alice and the third party independently establish an            ephemeral secret for the remaining setup communications as            S=S_(A)·P_(T)=P_(A)·S_(T).        -   iii. Alice and the third party begin communicating over a            channel, e.g. an AES-encrypted channel, secured by S.    -   4. The third party sends Alice a set of challenges C₁, C₂, . . .        , C_(n) over the secure channel.    -   5. Alice obtains the responses R₁, R₂, . . . , R_(n) from the        ePUF device.    -   6. Alice sends the third party the responses R₁, R₂, . . . , R,        over the secure channel.    -   7. The third party stores the responses CRP set {(C₁, R₁), (C₂,        R₂), . . . , (C_(n), R_(n))} against Alice's identity account.

Case 2: Third Party Accesses PUF During Setup

-   -   1. The third party has the knowledge of the base pair and the        hash function. E.g. the ePUF device is manufactured and        distributed to the trusted third party*. (* The device may be        first distributed to Alice, and then sent by Alice. However, in        most cases it will make more sense for the device to be        distributed directly to the third party. E.g. if the device is a        smart debit card, the card may be sent from manufacturer to the        issuing bank, and then from the issuing bank to the customer        Alice, following the PUF setup.)    -   2. The third party obtains the base CRP (C_(w), R_(w)) from the        device.    -   3. Alice applies for an identity-linked ePUF device by        contacting the third party. This may be done over an unsecured        communications channel.        -   i. The third party establishes an identification account for            Alice, and requests proof of her identity.        -   ii. Alice supplies the third party with the relevant            identification documents or credentials.        -   iii. The third party verifies Alice's identity and assigns            the ePUF device and its base pair (C_(w), R_(w)) to Alice's            account. The shared secret is, or is a derivative of, this            CRP.    -   4. The third party sends the ePUF device to Alice.

The setup protocol establishes a shared secret(s) between Alice and thetrusted third party to be used to authenticate Alice's identity (orPUF-containing device) at a later time during a verification process.The cases are also similar in that they both preferably involve securecommunication between Alice and the trusted third party.

However, a distinction between the two cases is that case 1 achieves thesecure communication by establishing a secure communication channel,whereas case 2 achieves it by means of physical security.

Another difference to note between the two protocols in case 1 and 2respectively, is that in case 2 the trusted third party can derive asmany CRPs without the PUF as Alice, while in case 1 this party has tostore a fixed number of pairs.

This is an advantage of case 2 over existing protocols for setting up auser with a PUF device because it allows the trusted third party togenerate an arbitrary number of CRPs remotely, whereas in existingprotocols the trusted third party may need to cooperate with either theend user or device manufacturer to do so. The same technical advantagemay be achieved in case 1 if the step is added of Alice sending the basepair (C_(w), R_(w)) to Bob over a secure channel (trusting the thirdparty not to use the base pair in a malicious way).

Note that the use of secure communication in the setup phase allows forfuture communications, such as the verification process, to betransmitted over unsecured channels. This has the benefit of allowingverifications to occur with fewer technical limitations, such as theneed for both parties to be online at the time of verification, and onlyrequires the additional secure communications overhead in this one-timesetup process.

3.1.2. Verification: In the mode of remote PUF verification, recall thatthere were two distinct cases in the setup phase, which are reflected inslightly differing remote verification protocols, as detailed below.

Case 1: Alice has sole access to PUF

-   -   1. Bob obtains an unused CRP, such as (C₁, R₁), from the set        {(C₁, R₁), (C₂, R₂), . . . , (C_(n), R_(n))} established by        Alice and the third-party during setup.        -   i. If Bob is also the trusted third party, he simply            retrieves an element from the set.        -   ii. If Bob is not the trusted third party, he communicates            with the third party by requesting an unused CRP for Alice.    -   2. Bob sends the challenge C₁ to Alice.    -   3. Alice obtains the candidate response R_(i) from her ePUF        device and sends it to Bob.    -   4. Bob verifies whether R₁==R₁:        -   i. If yes, the verification passes.        -   ii. If no, the verification fails.    -   5. The pair (C₁, R₁) is subsequently removed by the trusted        third party, leaving the set of remaining challenge-response        pairs {(C₂, R₂), (C₃, R₃), . . . , (C_(n), R_(n)))}.

Note that in step 1.ii. the single-use nature of the CRPs ensures thatit is not possible for an arbitrary Bob to ‘impersonate’ Alice using aparticular CRP, because the trusted third-party can simply monitor theuse of each pair in each given situation and should use a fresh CRP forevery authentication attempt.

Case 2: Third party accessed PUF during setup

-   -   1. Bob generates a fresh challenge C for the verification. This        may be done randomly, or deterministically from some other data        (e.g. known KYC data, biometrics, images).    -   2. Bob sends the challenge C to Alice.    -   3. Alice obtains the candidate response R′ from her ePUF device        and sends it to Bob.    -   4. Bob obtains the expected response R.        -   i. If Bob is the trusted third party, he is able to            calculate the response directly by computing R=hash(C,            R_(w), H)*. (* This is because the third party obtained the            base pair (C_(w), R_(w)) during setup protocol (case 2)            which implies that R, is known to them. It is also assumed            that the has function H is known to at least the third            party, if not everybody, i.e. is a public standard such as            SHA-256).        -   ii. If Bob is not the trusted third party, he sends C to the            third party and requests the response R.    -   5. Bob verifies whether R′==R:        -   i. If yes, the verification passes.        -   ii. If no, the verification fails.

3.1.3. Update: It may also be desirable to specify a process for Aliceand the third party to establish fresh CRPs given their single-usenature in verification (and other useful protocols, such as logins).

Case 1: Alice has sole access to PUF. In this case, another securechannel is established to transmit challenges and responses betweenAlice and the third party, as in the setup. We assume that Alice has atleast one remaining CRP of the form (C_(i), R_(i)) to establish a sharedsecret of the form S═H(R_(i)) or similar, or has access to a previousshared secret S=S_(A)·P_(T)=P_(A)·S_(T) from DH key-exchange.

-   -   1. Alice and the third party establish a secure communication        channel using a shared secret S. This can be derived in many        ways, the protocol is agnostic to this.    -   2. The third party sends Alice a set of challenges C₁, C₂, . . .        , C_(n) over the secure channel.    -   3. Alice obtains the responses R₁, R₂, . . . , R_(n) from the        ePUF device.    -   4. Alice sends the third party the responses R₁, R₂, . . . ,        R_(n) over the secure channel.    -   5. The third party stores the responses CRP set {(C₁, R₁), (C₂,        R₂), . . . , (C_(n), R_(n))} against Alice's identity account.

Note that steps 2-5 at least are identical to the setup steps 4-7.

See also the previous comment regarding Alice telling third party(C_(w), R_(w)) over the channel.

Case 2: Third party accessed PUF during setup. In this case, the thirdparty can generate an arbitrary number of CRPs indirectly, because theyhave knowledge of both the base pair (C_(w), R_(w)) and the hashfunction H( ). This means that there is no requirement for aninteractive update in this case.

3.1.4. Revocation: a further part of the identity system may be for aparticular ePUF device to be revoked, such that is it no longer used foridentity purposes. The revocation process is simple and can be performedas either (i) a revocation by the third party, independently of the userAlice, or (ii) a revocation by Alice conveyed as a revocation request.

The first case does not require any technological means involving ePUFsor otherwise. The second case does not require a protocol or solutionspecific to ePUFs, because a good example of the need for a revocationin the first case is if Alice has lost the physical device containingthe ePUF, or if it has been compromised in some way.

However, if it is desired to optionally leverage the ePUF in arevocation process, wherein Alice still has physical control of thedevice, then it may be prescribed that Alice's request is authenticatedusing one of the CRPs she and the third party have established (orderived shared secret thereof) such as by means of an HMAC or anencrypted message using a CRP response or secret as the key in eachcase. For the reason mentioned above, however, this is not considered astrict requirement of the system by any means.

3.2. Local PUF System

3.2.1. Setup: the setup that can be employed for the local PUF isexactly the same as the setup for the remote PUF, but a differencebetween the local and remote cases is how the verification step iscarried out below.

3.2.2. Verification: In this scenario, a verification is being performedlocally. This means that the verification process requires that both theprover (Alice) and verifier (Bob) are in the same physical location.

This scenario may be relevant for example to court proceedings (forhuman identity), where Alice is legally required to interact with aninvestigation locally using her ePUF device, or where an analysis of anIoT system is to be performed (for device identity) where anadministrator of a system may wish to explicitly check the response of aparticular device locally. It may also be relevant to payment scenarios.

Other scenarios to which such a process is applicable could includediagnostics on a vehicle after a crash, where the authorities wish todetermine exactly which digital component issued an instruction. In thiscase, the input C may be some environmental or dynamics conditions, andthe response R would be part of the instruction that was given by thedevice.

A distinction between the local PUF verification protocol, outlinedbelow, and the previous remote PUF verification protocols is that thislocal protocol does not assume the verifier has knowledge of the ePUF'sresponse ahead of time. In other words, the response generated duringthe local verification process is not available to the verifier ahead oftime. It is likely in this scenario, however, that the challenge used inthe verification process is meaningful in some way. For example,consider a machine whose identity can be considered to be the base pair(C_(w), R_(w)) of its embedded ePUF component. The verification processmay be performed to verify that it was this particular device thatpreviously yielded an output R from a given input C.

-   -   1. Bob obtains the relevant challenge C to submit to the ePUF        device, based on the CRP in question (C, R).    -   2. Bob gains access to the ePUF device.    -   3. Bob uses the ePUF device to generate the candidate response        R′=hash(C, R_(w), H).    -   4. Bob verifies whether R′==R:        -   i. If yes, the verification passes.        -   ii. If no, the verification fails.

In these scenarios Bob does not know the candidate response R′ ahead oftime, but rather is verifying that the response he now receives from thePUF device matches a previously generated response. For instance thiscan be used to verify (e.g. in court) that a person (Alice) or a devicethat prevails produced a response is the same person or device that isnow present (e.g. in the court). E.g. in the example of the digitalcomponent, this would have been configured to issue the instruction upongeneration of R based on some input challenge C. E.g. if the device is aself-driving car and the component receives a challenge derived from orcomprising the data “the car in front is too close” then the response Ris generated, and R triggers the component to issue the instruction toapply the brakes. So in the retrospective diagnostic verification, theverifier believes the car slowed down and wishes to verify that theconditions were actually that “the car in front was too close” totrigger that response.

3.2.3. Update: The process for generating updated CRPs can follow thesame logic as put forward for the remote case, as the key difference inthat scenario only applies to verification.

3.2.4 Revocation: the same techniques described for remote revocation inare also valid here.

3.3. Cryptographic PUF System

3.3.1 Setup: In this case, Alice establishes an identity with a thirdparty using standard cryptographic means, but using an ePUF device inthe process.

In this scenario, the third party may optionally have knowledge that anePUF has been used in the process. Similarly, for an identityestablished in this manner, the verifier of an identity may or may notknow that an ePUF device is involved in the identity verificationprocess. In short, the following protocol only stipulates that the ownerof the device, Alice, has knowledge that an ePUF device is involved inthe identity system.

-   -   1. The ePUF device is manufactured and distributed to Alice.    -   2. Alice applies to establish a cryptographic identity by        contacting a trusted third party.        -   i. The third party establishes an identification account for            Alice, and requests proof of her identity.        -   ii. Alice supplies the third party with the relevant            identification documents or credentials.        -   iii. The third party verifies Alice's identity.    -   3. Alice chooses a cryptographic method for establishing a        cryptographic link to her identity, e.g. establishing a        certified asymmetric key-pair using her CRP.        -   i. The third party obtains a public key P_(A) from Alice,            where P_(A)=s_(A)·G is an EC key pair.        -   ii. The third party requests that Alice signs (e.g. via            ECDSA) a message m using the private key s_(A).        -   iii. Alice generates the ECDSA signature Sig(P_(A),m) and            sends to the third party.        -   iv. The third party verifies the signature.    -   4. If the signature is valid, the third party certifies the key        P_(A) against Alice's identity.

Step 3 involves using a cryptographic scheme of the user's choice, butthat we assume the relevant key involve in the process will be aderivative of a CRP response known only to Alice. In the example chosenabove, this means that the private key S_(A) would be derived from aparticular ePUF response R, such as S_(A)=H(R).

3.3.2 Verification: In the cryptographic case, the identity verificationis performed using cryptographic information that was established duringthe cryptographic setup phase detailed previously. In this case, we takethe example that a certified EC asymmetric key-pair was establishedagainst Alice's identity during setup, and we now use that key forverification.

The protocol below could, however, be simply adapted for any othercryptographic scheme simply by substituting the existing setup andverification protocols for those schemes where appropriate. A differencehere is using an ePUF device as a secure key-generator for the setup andverification process, which reduce the risk of malicious compromise tothe holder Alice.

-   -   1. Bob obtains the identity-linked information P_(A), e.g. a        certified key.        -   i. If Bob is the trusted third party, he simply retrieves            P_(A) from Alice's account.        -   ii. If Bob is not the trusted third party, he communicates            with the third party and requests a certified public key for            Alice.    -   2. Bob chooses a message m for Alice to sign, and sends to        Alice.    -   3. Alice generates a signature over the message m.        -   i. If Alice wishes to sign with her certified key, she            generates the signature Sig(P_(A), n).        -   ii. If Alice wishes to sign with a single-use derived key,            she generates the signature Sig(P_(α), m), where            P_(α)=P_(A)+H(d)·G and d is some single-use data*. (* This            data may be related to the verification, such as an invoice            message, or biometric fuzzy-matching data. The data d may be            chosen by Bob or Alice. Alternatively, d may be a shared            secret known to Alice and Bob e.g. derived using            Diffie-Hellman key exchange and/or an HMAC.)    -   4. Alice sends the signature to Bob. At this point, Alice may        also send the data d if Bob does not already know it.    -   5. Bob verifies the signature against the public key using P_(A)        (and d, if applicable).        -   i. If the signature verification passes, the identity            verification passes.        -   ii. If the signature verification fails, the identity            verification fails.

The cryptographic verification process above may also apply to anidentity established independently, as described in the previoussection, if the identity was established with a similar cryptographicprimitive such as an EC or PGP key.

3.3.3. Update: the process of updating Alice's identity here is notdependent on the use of the ePUF device in key-generation, and as suchit is not necessary to prescribe any particular method here. Instead,standard methods for updating a certified key such as P_(A) may be used.

It may simply be assumed that the ePUF will be involved inkey-generation for any required signatures or other cryptographicprocess required by the existing process(es).

3.3.4. Revocation: Similarly, it is not necessary to prescribe aparticular revocation protocol here, but defer to standard mechanisms.Once more, it may be assumed that the ePUF will be involved in thebackground as a key-generator for the relevant cryptographic operations.

3.4. Independent PUF Mechanism

3.4.1 Setup: In the independent case for establishing an identity usingan ePUF device, consider the scenario where an entity wishes toestablish either a human identity independently of any third party, or adevice identity within a closed system. The only party involved in thisprocess is Alice, the ‘owner’ of the ePUF device and the eventual proverduring later verifications.

Case 1: Alice establishes human identity

-   -   1. Alice obtains an ePUF device.    -   2. Alice probes the ePUF with a challenge C.    -   3. Alice obtains the response R from the ePUF.    -   4. Alice uses the pair (C, R) to establish an identity for        herself:        -   i. Alice may use a cryptographic setup to establish a            non-certified identity key P_(A).        -   ii. Alice publishes her identity key against her identity.    -   5. Alice may wish to publish attestations to her CRP, such as        the double-hash H²(R) of the response.

This case, where Alice establishes a ‘self-sovereign’ identity forherself, is useful to an extent in providing a unique and reproducibledevice identifier for a device that only she controls. However, the lackof a trusted third party in such an identity system means that averifier must later trust the link between the prover's identity and theprover's device. This may have very limited applications in the realworld.

Case 2: Alice established identity for a device

-   -   1. Alice obtains an ePUF device.    -   2. Alice probes the ePUF with a challenge C.    -   3. Alice obtains the response R from the ePUF.    -   4. Alice uses the pair (C, R) to establish an identity for the        device within her system:        -   i. Alice maps the pair (C, R) to her device.        -   ii. Alice keeps a database of all her devices and CRP            mappings.    -   5. Alice may wish to publish attestations to her CRP, such as        the double-hash H²(R) of the response.

In the case above, where we create a ‘self-sovereign’ identity for adevice, it can be seen that the design may be highly useful within aclosed system, where an administrator is simply looking to identifydifferent devices within that system. This may also be useful forattesting to others later on. However, the lack of a trusted third partyduring setup still limits the prover in convincing an external verifierthat the devices have not been changed, depending on the scenario.

Note that case 1 and case 2 may be considered as the same process butwith a different intended purpose. Therefore case 1 and case 2 may betaken together as a method for generating a ‘self-sovereign’ identity,for human or machine, where in the latter case the system administrator(such as Alice, in an IoT system) is a trusted entity herself. In bothcases, Alice is the trusted entity.

3.4.2 Verification: The verification process for this case is as simpleas probing the ePUF device with a given challenge and inspecting itsresponse. More complex proofs or evidence for external parties may needto be built on top of this to prove the identity to them.

3.4.3 Update: the update process for this case is simply a repetition ofthe setup process, where the administrator (in this case Alice)enumerates additional CRPs for forward use.

3.4.4. Revocation: in this scenario, the only type of identityrevocation is the case where the administrator (Alice) wishes toindependently revoke the identity, as there is no third party involve inthis process. This means that revocation may be as simple as Alice'scessation of use of the ePUF device, and the purging of her database ofits CRPs.

In a later section, ways are disclosed in which this self-sovereignrevocation can be made more robust by blockchain attestation andevidencing, such that it may convince an external party at a later time.

3.5. Identity-Based CRP Management

In the above, especially the remote PUF-based identity system, thesingle-use nature of the CRPs used to authenticate identity in the setupand verification protocols presents a CRP-management challenge for theinvolved parties.

For instance, in the cases where the trusted third-party does not accessthe PUF device during setup, it may be desired that many CRPs areenumerated {(C₁, R₁), (C₂, R₂), . . . , (C_(n), R_(n))} for the thirdparty to store for future verifications.

Moreover, because the ePUF itself acts as a deterministic pseudo-randommapping of challenges to responses, the responses will appear mutuallyunrelated. Therefore the burden on the trusted third party to tabulateand store sets of CRPs for their users or clients will quickly present ascaling issue if they must service a large number of users.

FIG. 8A illustrates a deterministic derivation of challenges fromidentification data in accordance with embodiments disclosed herein.

According to such embodiments, in order to address the issue of theburden on the trusted third party, CRP management is handled primarilyin the generation of the challenges C₁, C₂, . . . , C_(n). The idea hereis that the challenges should be derived deterministically (and possiblyalso hierarchically) from a single master challenge, or master data fromwhich a master challenge is derived. This concept is similar to the useof hierarchical deterministic (HD) wallets to manage single-use Bitcoinkeys, in that it is designed to allow the trusted third-party (oranother relevant party) to recover all relevant challenges using onlythe master data, which is termed a ‘wallet seed’ in the Bitcoinscenario.

In some such embodiments, identification data 806 of Alice (the targetparty 103T) is used as the master data for generating a large range ofchallenges to determine which CRPs are used in identity systems such asthose proposed in the previous sections. The identification data itselfmay comprise a combination 804 of different data elements 802, but incombination they preferably have the following properties:

-   -   Uniqueness—the identification data is unique to the entity it        pertains to; and    -   Secrecy—the identification data is known only to the entity (or        owner thereof) it pertains to.

Simple examples of constituents to the identification data may include apassport number, national insurance number, names, birth date, or theanswers to a security question (e.g. mother's maiden name), or serialnumbers and manufacturing information in the case of deviceidentification. However, it is perceived that data obtained by moreadvanced technological means may also be used, such as fingerprint orfacial recognition data, which may be extracted using fuzzy-magictechniques to conserve uniqueness.

In embodiments, the ‘identification data’ used as the master input, fromwhich a set of challenges are derived, may comprise a multiplicity ofthe above. One reason for this is to ensure that the informationpreserves secrecy with respect to as many trusted third-parties aspossible, given that as some of the protocols in the previous sectionsrely on sharing challenges with the third-party and/or with an externalverifying party. Identification data comprising multiple components willbe harder for any third-party so fully duplicate without the consent ofthe proving party Alice.

A mechanism for deterministically generating CRPs using identificationdata is shown in FIG. 8A. The constituent parts of the identificationdata are first combined by process ‘A’ (804), which may beconcatenation, bitwise operations (e.g. XOR) or any other relevantcombination operation, with a note that this operation may seek topreserve privacy by converting the raw data into an obfuscated form.

The identifying data is then turned into a master challenge Cm, by meansof a hash function or similar process. Finally, the master challenge isused to deterministically derive a sequence of single-use challenges C₁,C₂, . . . , C_(n) using a derivation function ƒ( ). In embodiments, asshown in FIG. 8B, the derivation function f( ) may comprise a hashfunction and the injection of a nonce, such that each successivechallenge is generated as C_(i)=SHA256(C_(i-1), i), where i serves asthe nonce.

The process A, the generation of a challenge Cm from identificationdata, and the derivation function ƒ( ) may all be configured dependingon the needs of the particular implementation.

FIG. 8C shows another particular example, namely a hierarchical anddeterministic derivation of challenges (responses not pictured). It maybe desirable to derive the single-use challenges C_(i) from the masterC_(m) in a hierarchical manner, as shown in FIG. 8B. In this case,CRP-management is further improved by the fact that the generation of aparticular challenge does not need to depend on all of the previouschallenges, as in the previous case.

The use of deterministic derivation of challenges based on identity datareduces the storage overhead for both the prover Alice and the trustedthird-party in identity protocols. It is possible for either party toonly store the (or a subset of) the identifying data, and recompute thenecessary challenges as and when required.

In addition, Alice also has the option to tailor her privacy by choosingto withhold or share as much information with each identificationservice as desired, with the trade-off that she may store more dataherself.

4. EXAMPLE BLOCKCHAIN SYSTEM

The following describes an example blockchain system that may beemployed in certain embodiments of the present disclosure. Note that“Alice” and “Bob” are just arbitrary names for two parties, and Aliceand Bob do not necessarily have the same roles in this section as in thepreceding section or following sections.

In some embodiments, response data based on the output of a PUF may bestored on chain, for instance as discussed in the preceding section. Theresponse data stored on chain may take the form of the actual responseitself, or a transformation of it such as a hash or double hash (aso-called attestation or hash-commit), or a public key of apublic-private key pair derived from the PUF response. Whatever form theon-chain response data takes, it is something that enables another,verifying party to check whether a target response or signaturepresented as evidence of identity is as expected. In furtherembodiments, the blockchain may be used as a means to managechallenge-response pairs, such as to update or revoke them.

The following describes an example of a blockchain system that may beused to implement such features.

4.1. Example System Overview

FIG. 1 shows an example system 100 for implementing a blockchain 150.The system 100 may comprise a packet-switched network 101, typically awide-area internetwork such as the Internet. The packet-switched network101 comprises a plurality of blockchain nodes 104 that may be arrangedto form a peer-to-peer (P2P) network 106 within the packet-switchednetwork 101. Whilst not illustrated, the blockchain nodes 104 may bearranged as a near-complete graph. Each blockchain node 104 is thereforehighly connected to other blockchain nodes 104.

Each blockchain node 104 comprises computer equipment of a peer, withdifferent ones of the nodes 104 belonging to different peers. Eachblockchain node 104 comprises processing apparatus comprising one ormore processors, e.g. one or more central processing units (CPUs),accelerator processors, application specific processors and/or fieldprogrammable gate arrays (FPGAs), and other equipment such asapplication specific integrated circuits (ASICs). Each node alsocomprises memory, i.e. computer-readable storage in the form of anon-transitory computer-readable medium or media. The memory maycomprise one or more memory units employing one or more memory media,e.g. a magnetic medium such as a hard disk; an electronic medium such asa solid-state drive (SSD), flash memory or EEPROM; and/or an opticalmedium such as an optical disk drive.

The blockchain 150 comprises a chain of blocks of data 151, wherein arespective copy of the blockchain 150 is maintained at each of aplurality of blockchain nodes 104 in the distributed or blockchainnetwork 106. As mentioned above, maintaining a copy of the blockchain150 does not necessarily mean storing the blockchain 150 in full.Instead, the blockchain 150 may be pruned of data so long as eachblockchain node 150 stores the block header (discussed below) of eachblock 151. Each block 151 in the chain comprises one or moretransactions 152, wherein a transaction in this context refers to a kindof data structure. The nature of the data structure will depend on thetype of transaction protocol used as part of a transaction model orscheme. A given blockchain will use one particular transaction protocolthroughout. In one common type of transaction protocol, the datastructure of each transaction 152 comprises at least one input and atleast one output. Each output specifies an amount representing aquantity of a digital asset as property, an example of which is a user103 to whom the output is cryptographically locked (requiring asignature or other solution of that user in order to be unlocked andthereby redeemed or spent). Each input points back to the output of apreceding transaction 152, thereby linking the transactions.

Each block 151 also comprises a block pointer 155 pointing back to thepreviously created block 151 in the chain so as to define a sequentialorder to the blocks 151. Each transaction 152 (other than a coinbasetransaction) comprises a pointer back to a previous transaction so as todefine an order to sequences of transactions (N.B. sequences oftransactions 152 are allowed to branch). The chain of blocks 151 goesall the way back to a genesis block (Gb) 153 which was the first blockin the chain. One or more original transactions 152 early on in thechain 150 pointed to the genesis block 153 rather than a precedingtransaction.

Each of the blockchain nodes 104 is configured to forward transactions152 to other blockchain nodes 104, and thereby cause transactions 152 tobe propagated throughout the network 106. Each blockchain node 104 isconfigured to create blocks 151 and to store a respective copy of thesame blockchain 150 in their respective memory. Each blockchain node 104also maintains an ordered set (or “pool”) 154 of transactions 152waiting to be incorporated into blocks 151. The ordered pool 154 isoften referred to as a “mempool”.

This term herein is not intended to limit to any particular blockchain,protocol or model. It refers to the ordered set of transactions which anode 104 has accepted as valid and for which the node 104 is obliged notto accept any other transactions attempting to spend the same output.

In a given present transaction 152 j, the (or each) input comprises apointer referencing the output of a preceding transaction 152 i in thesequence of transactions, specifying that this output is to be redeemedor “spent” in the present transaction 152 j. In general, the precedingtransaction could be any transaction in the ordered set 154 or any block151. The preceding transaction 152 i need not necessarily exist at thetime the present transaction 152 j is created or even sent to thenetwork 106, though the preceding transaction 152 i will need to existand be validated in order for the present transaction to be valid. Hence“preceding” herein refers to a predecessor in a logical sequence linkedby pointers, not necessarily the time of creation or sending in atemporal sequence, and hence it does not necessarily exclude that thetransactions 152 i, 152 j be created or sent out-of-order (seediscussion below on orphan transactions). The preceding transaction 152i could equally be called the antecedent or predecessor transaction.

The input of the present transaction 152 j also comprises the inputauthorisation, for example the signature of the user 103 a to whom theoutput of the preceding transaction 152 i is locked. In turn, the outputof the present transaction 152 j can be cryptographically locked to anew user or entity 103 b. The present transaction 152 j can thustransfer the amount defined in the input of the preceding transaction152 i to the new user or entity 103 b as defined in the output of thepresent transaction 152 j. In some cases a transaction 152 may havemultiple outputs to split the input amount between multiple users orentities (one of whom could be the original user or entity 103 a inorder to give change). In some cases a transaction can also havemultiple inputs to gather together the amounts from multiple outputs ofone or more preceding transactions, and redistribute to one or moreoutputs of the current transaction.

According to an output-based transaction protocol such as bitcoin, whena party 103, such as an individual user or an organization, wishes toenact a new transaction 152 j (either manually or by an automatedprocess employed by the party), then the enacting party sends the newtransaction from its computer terminal 102 to a recipient. The enactingparty or the recipient will eventually send this transaction to one ormore of the blockchain nodes 104 of the network 106 (which nowadays aretypically servers or data centres, but could in principle be other userterminals). It is also not excluded that the party 103 enacting the newtransaction 152 j could send the transaction directly to one or more ofthe blockchain nodes 104 and, in some examples, not to the recipient. Ablockchain node 104 that receives a transaction checks whether thetransaction is valid according to a blockchain node protocol which isapplied at each of the blockchain nodes 104. The blockchain nodeprotocol typically requires the blockchain node 104 to check that acryptographic signature in the new transaction 152 j matches theexpected signature, which depends on the previous transaction 152 i inan ordered sequence of transactions 152. In such an output-basedtransaction protocol, this may comprise checking that the cryptographicsignature or other authorisation of the party 103 included in the inputof the new transaction 152 j matches a condition defined in the outputof the preceding transaction 152 i which the new transaction assigns,wherein this condition typically comprises at least checking that thecryptographic signature or other authorisation in the input of the newtransaction 152 j unlocks the output of the previous transaction 152 ito which the input of the new transaction is linked to. The conditionmay be at least partially defined by a script included in the output ofthe preceding transaction 152 i. Alternatively it could simply be fixedby the blockchain node protocol alone, or it could be due to acombination of these. Either way, if the new transaction 152 j is valid,the blockchain node 104 forwards it to one or more other blockchainnodes 104 in the blockchain network 106. These other blockchain nodes104 apply the same test according to the same blockchain node protocol,and so forward the new transaction 152 j on to one or more further nodes104, and so forth. In this way the new transaction is propagatedthroughout the network of blockchain nodes 104.

In an output-based model, the definition of whether a given output (e.g.UTXO) is assigned (e.g. spent) is whether it has yet been validlyredeemed by the input of another, onward transaction 152 j according tothe blockchain node protocol. Another condition for a transaction to bevalid is that the output of the preceding transaction 152 i which itattempts to redeem has not already been redeemed by another transaction.Again if not valid, the transaction 152 j will not be propagated (unlessflagged as invalid and propagated for alerting) or recorded in theblockchain 150. This guards against double-spending whereby thetransactor tries to assign the output of the same transaction more thanonce. An account-based model on the other hand guards againstdouble-spending by maintaining an account balance. Because again thereis a defined order of transactions, the account balance has a singledefined state at any one time.

In addition to validating transactions, blockchain nodes 104 also raceto be the first to create blocks of transactions in a process commonlyreferred to as mining, which is supported by “proof-of-work”. At ablockchain node 104, new transactions are added to an ordered pool 154of valid transactions that have not yet appeared in a block 151 recordedon the blockchain 150. The blockchain nodes then race to assemble a newvalid block 151 of transactions 152 from the ordered set of transactions154 by attempting to solve a cryptographic puzzle. Typically thiscomprises searching for a “nonce” value such that when the nonce isconcatenated with a representation of the ordered pool of pendingtransactions 154 and hashed, then the output of the hash meets apredetermined condition. E.g. the predetermined condition may be thatthe output of the hash has a certain predefined number of leading zeros.Note that this is just one particular type of proof-of-work puzzle, andother types are not excluded. A property of a hash function is that ithas an unpredictable output with respect to its input. Therefore thissearch can only be performed by brute force, thus consuming asubstantive amount of processing resource at each blockchain node 104that is trying to solve the puzzle.

The first blockchain node 104 to solve the puzzle announces this to thenetwork 106, providing the solution as proof which can then be easilychecked by the other blockchain nodes 104 in the network (once given thesolution to a hash it is straightforward to check that it causes theoutput of the hash to meet the condition). The first blockchain node 104propagates a block to a threshold consensus of other nodes that acceptthe block and thus enforce the protocol rules. The ordered set oftransactions 154 then becomes recorded as a new block 151 in theblockchain 150 by each of the blockchain nodes 104. A block pointer 155is also assigned to the new block 151 n pointing back to the previouslycreated block 151 n-1 in the chain. The significant amount of effort,for example in the form of hash, required to create a proof-of-worksolution signals the intent of the first node 104 to follow the rules ofthe blockchain protocol. Such rules include not accepting a transactionas valid if it assigns the same output as a previously validatedtransaction, otherwise known as double-spending. Once created, the block151 cannot be modified since it is recognized and maintained at each ofthe blockchain nodes 104 in the blockchain network 106. The blockpointer 155 also imposes a sequential order to the blocks 151. Since thetransactions 152 are recorded in the ordered blocks at each blockchainnode 104 in a network 106, this therefore provides an immutable publicledger of the transactions.

Note that different blockchain nodes 104 racing to solve the puzzle atany given time may be doing so based on different snapshots of the poolof yet-to-be published transactions 154 at any given time, depending onwhen they started searching for a solution or the order in which thetransactions were received. Whoever solves their respective puzzle firstdefines which transactions 152 are included in the next new block 151 nand in which order, and the current pool 154 of unpublished transactionsis updated. The blockchain nodes 104 then continue to race to create ablock from the newly-defined ordered pool of unpublished transactions154, and so forth. A protocol also exists for resolving any “fork” thatmay arise, which is where two blockchain nodes 104 solve their puzzlewithin a very short time of one another such that a conflicting view ofthe blockchain gets propagated between nodes 104. In short, whicheverprong of the fork grows the longest becomes the definitive blockchain150. Note this should not affect the users or agents of the network asthe same transactions will appear in both forks.

According to the bitcoin blockchain (and most other blockchains) a nodethat successfully constructs a new block 104 is granted the ability tonewly assign an additional, accepted amount of the digital asset in anew special kind of transaction which distributes an additional definedquantity of the digital asset (as opposed to an inter-agent, orinter-user transaction which transfers an amount of the digital assetfrom one agent or user to another). This special type of transaction isusually referred to as a “coinbase transaction”, but may also be termedan “initiation transaction” or “generation transaction”. It typicallyforms the first transaction of the new block 151 n. The proof-of-worksignals the intent of the node that constructs the new block to followthe protocol rules allowing this special transaction to be redeemedlater. The blockchain protocol rules may require a maturity period, forexample 100 blocks, before this special transaction may be redeemed.Often a regular (non-generation) transaction 152 will also specify anadditional transaction fee in one of its outputs, to further reward theblockchain node 104 that created the block 151 n in which thattransaction was published. This fee is normally referred to as the“transaction fee”, and is discussed blow.

Due to the resources involved in transaction validation and publication,typically at least each of the blockchain nodes 104 takes the form of aserver comprising one or more physical server units, or even whole adata centre. However in principle any given blockchain node 104 couldtake the form of a user terminal or a group of user terminals networkedtogether.

The memory of each blockchain node 104 stores software configured to runon the processing apparatus of the blockchain node 104 in order toperform its respective role or roles and handle transactions 152 inaccordance with the blockchain node protocol. It will be understood thatany action attributed herein to a blockchain node 104 may be performedby the software run on the processing apparatus of the respectivecomputer equipment. The node software may be implemented in one or moreapplications at the application layer, or a lower layer such as theoperating system layer or a protocol layer, or any combination of these.

Also connected to the network 101 is the computer equipment 102 of eachof a plurality of parties 103 in the role of consuming users. Theseusers may interact with the blockchain network 106 but do notparticipate in validating transactions or constructing blocks. Some ofthese users or agents 103 may act as senders and recipients intransactions. Other users may interact with the blockchain 150 withoutnecessarily acting as senders or recipients. For instance, some partiesmay act as storage entities that store a copy of the blockchain 150(e.g. having obtained a copy of the blockchain from a blockchain node104).

Some or all of the parties 103 may be connected as part of a differentnetwork, e.g. a network overlaid on top of the blockchain network 106.Users of the blockchain network (often referred to as “clients”) may besaid to be part of a system that includes the blockchain network 106;however, these users are not blockchain nodes 104 as they do not performthe roles required of the blockchain nodes. Instead, each party 103 mayinteract with the blockchain network 106 and thereby utilize theblockchain 150 by connecting to (i.e. communicating with) a blockchainnode 106. Two parties 103 and their respective equipment 102 are shownfor illustrative purposes: a first party 103 a and his/her respectivecomputer equipment 102 a, and a second party 103 b and his/herrespective computer equipment 102 b. It will be understood that manymore such parties 103 and their respective computer equipment 102 may bepresent and participating in the system 100, but for convenience theyare not illustrated. Each party 103 may be an individual or anorganization. Purely by way of illustration the first party 103 a isreferred to herein as Alice and the second party 103 b is referred to asBob, but it will be appreciated that this is not limiting and anyreference herein to Alice or Bob may be replaced with “first party” and“second “party” respectively.

The computer equipment 102 of each party 103 comprises respectiveprocessing apparatus comprising one or more processors, e.g. one or moreCPUs, GPUs, other accelerator processors, application specificprocessors, and/or FPGAs. The computer equipment 102 of each party 103further comprises memory, i.e. computer-readable storage in the form ofa non-transitory computer-readable medium or media. This memory maycomprise one or more memory units employing one or more memory media,e.g. a magnetic medium such as hard disk; an electronic medium such asan SSD, flash memory or EEPROM; and/or an optical medium such as anoptical disc drive. The memory on the computer equipment 102 of eachparty 103 stores software comprising a respective instance of at leastone client application 105 arranged to run on the processing apparatus.It will be understood that any action attributed herein to a given party103 may be performed using the software run on the processing apparatusof the respective computer equipment 102. The computer equipment 102 ofeach party 103 comprises at least one user terminal, e.g. a desktop orlaptop computer, a tablet, a smartphone, or a wearable device such as asmartwatch. The computer equipment 102 of a given party 103 may alsocomprise one or more other networked resources, such as cloud computingresources accessed via the user terminal.

The client application 105 may be initially provided to the computerequipment 102 of any given party 103 on suitable computer-readablestorage medium or media, e.g. downloaded from a server, or provided on aremovable storage device such as a removable SSD, flash memory key,removable EEPROM, removable magnetic disk drive, magnetic floppy disk ortape, optical disk such as a CD or DVD ROM, or a removable opticaldrive, etc.

The client application 105 comprises at least a “wallet” function. Thishas two main functionalities. One of these is to enable the respectiveparty 103 to create, authorise (for example sign) and send transactions152 to one or more bitcoin nodes 104 to then be propagated throughoutthe network of blockchain nodes 104 and thereby included in theblockchain 150. The other is to report back to the respective party theamount of the digital asset that he or she currently owns. In anoutput-based system, this second functionality comprises collating theamounts defined in the outputs of the various 152 transactions scatteredthroughout the blockchain 150 that belong to the party in question.

Note: whilst the various client functionality may be described as beingintegrated into a given client application 105, this is not necessarilylimiting and instead any client functionality described herein mayinstead be implemented in a suite of two or more distinct applications,e.g. interfacing via an API, or one being a plug-in to the other. Moregenerally the client functionality could be implemented at theapplication layer or a lower layer such as the operating system, or anycombination of these. The following will be described in terms of aclient application 105 but it will be appreciated that this is notlimiting.

The instance of the client application or software 105 on each computerequipment 102 is operatively coupled to at least one of the blockchainnodes 104 of the network 106. This enables the wallet function of theclient 105 to send transactions 152 to the network 106. The client 105is also able to contact blockchain nodes 104 in order to query theblockchain 150 for any transactions of which the respective party 103 isthe recipient (or indeed inspect other parties' transactions in theblockchain 150, since in embodiments the blockchain 150 is a publicfacility which provides trust in transactions in part through its publicvisibility). The wallet function on each computer equipment 102 isconfigured to formulate and send transactions 152 according to atransaction protocol. As set out above, each blockchain node 104 runssoftware configured to validate transactions 152 according to theblockchain node protocol, and to forward transactions 152 in order topropagate them throughout the blockchain network 106. The transactionprotocol and the node protocol correspond to one another, and a giventransaction protocol goes with a given node protocol, togetherimplementing a given transaction model. The same transaction protocol isused for all transactions 152 in the blockchain 150. The same nodeprotocol is used by all the nodes 104 in the network 106.

When a given party 103, say Alice, wishes to send a new transaction 152j to be included in the blockchain 150, then she formulates the newtransaction in accordance with the relevant transaction protocol (usingthe wallet function in her client application 105). She then sends thetransaction 152 from the client application 105 to one or moreblockchain nodes 104 to which she is connected. E.g. this could be theblockchain node 104 that is best connected to Alice's computer 102. Whenany given blockchain node 104 receives a new transaction 152 j, ithandles it in accordance with the blockchain node protocol and itsrespective role. This comprises first checking whether the newlyreceived transaction 152 j meets a certain condition for being “valid”,examples of which will be discussed in more detail shortly. In sometransaction protocols, the condition for validation may be configurableon a per-transaction basis by scripts included in the transactions 152.Alternatively the condition could simply be a built-in feature of thenode protocol, or be defined by a combination of the script and the nodeprotocol.

On condition that the newly received transaction 152 j passes the testfor being deemed valid (i.e. on condition that it is “validated”), anyblockchain node 104 that receives the transaction 152 j will add the newvalidated transaction 152 to the ordered set of transactions 154maintained at that blockchain node 104. Further, any blockchain node 104that receives the transaction 152 j will propagate the validatedtransaction 152 onward to one or more other blockchain nodes 104 in thenetwork 106. Since each blockchain node 104 applies the same protocol,then assuming the transaction 152 j is valid, this means it will soon bepropagated throughout the whole network 106.

Once admitted to the ordered pool of pending transactions 154 maintainedat a given blockchain node 104, that blockchain node 104 will startcompeting to solve the proof-of-work puzzle on the latest version oftheir respective pool of 154 including the new transaction 152 (recallthat other blockchain nodes 104 may be trying to solve the puzzle basedon a different pool of transactions 154, but whoever gets there firstwill define the set of transactions that are included in the latestblock 151. Eventually a blockchain node 104 will solve the puzzle for apart of the ordered pool 154 which includes Alice's transaction 152 j).Once the proof-of-work has been done for the pool 154 including the newtransaction 152 j, it immutably becomes part of one of the blocks 151 inthe blockchain 150. Each transaction 152 comprises a pointer back to anearlier transaction, so the order of the transactions is also immutablyrecorded.

Different blockchain nodes 104 may receive different instances of agiven transaction first and therefore have conflicting views of whichinstance is ‘valid’ before one instance is published in a new block 151,at which point all blockchain nodes 104 agree that the publishedinstance is the only valid instance. If a blockchain node 104 acceptsone instance as valid, and then discovers that a second instance hasbeen recorded in the blockchain 150 then that blockchain node 104 mustaccept this and will discard (i.e. treat as invalid) the instance whichit had initially accepted (i.e. the one that has not been published in ablock 151).

An alternative type of transaction protocol operated by some blockchainnetworks may be referred to as an “account-based” protocol, as part ofan account-based transaction model. In the account-based case, eachtransaction does not define the amount to be transferred by referringback to the UTXO of a preceding transaction in a sequence of pasttransactions, but rather by reference to an absolute account balance.The current state of all accounts is stored, by the nodes of thatnetwork, separate to the blockchain and is updated constantly. In such asystem, transactions are ordered using a running transaction tally ofthe account (also called the “position”). This value is signed by thesender as part of their cryptographic signature and is hashed as part ofthe transaction reference calculation. In addition, an optional datafield may also be signed the transaction. This data field may point backto a previous transaction, for example if the previous transaction ID isincluded in the data field.

4.2. UTXO-Based Model

FIG. 2 illustrates an example transaction protocol. This is an exampleof a UTXO-based protocol. A transaction 152 (abbreviated “Tx”) is thefundamental data structure of the blockchain 150 (each block 151comprising one or more transactions 152). The following will bedescribed by reference to an output-based or “UTXO” based protocol.However, this is not limiting to all possible embodiments. Note thatwhile the example UTXO-based protocol is described with reference tobitcoin, it may equally be implemented on other example blockchainnetworks.

In a UTXO-based model, each transaction (“Tx”) 152 comprises a datastructure comprising one or more inputs 202, and one or more outputs203. Each output 203 may comprise an unspent transaction output (UTXO),which can be used as the source for the input 202 of another newtransaction (if the UTXO has not already been redeemed). The UTXOincludes a value specifying an amount of a digital asset. Thisrepresents a set number of tokens on the distributed ledger. The UTXOmay also contain the transaction ID of the transaction from which itcame, amongst other information. The transaction data structure may alsocomprise a header 201, which may comprise an indicator of the size ofthe input field(s) 202 and output field(s) 203. The header 201 may alsoinclude an ID of the transaction. In embodiments the transaction ID isthe hash of the transaction data (excluding the transaction ID itself)and stored in the header 201 of the raw transaction 152 submitted to thenodes 104.

Say Alice 103 a wishes to create a transaction 152 j transferring anamount of the digital asset in question to Bob 103 b. In FIG. 2 Alice'snew transaction 152 j is labelled “Tx₁”. It takes an amount of thedigital asset that is locked to Alice in the output 203 of a precedingtransaction 152 i in the sequence, and transfers at least some of thisto Bob. The preceding transaction 152 i is labelled “Tx₀” in FIG. 2 .Tx₀ and Tx₁ are just arbitrary labels. They do not necessarily mean thatTx₀ is the first transaction in the blockchain 151, nor that Tx₁ is theimmediate next transaction in the pool 154. Tx₁ could point back to anypreceding (i.e. antecedent) transaction that still has an unspent output203 locked to Alice.

The preceding transaction Tx₀ may already have been validated andincluded in a block 151 of the blockchain 150 at the time when Alicecreates her new transaction Tx₁, or at least by the time she sends it tothe network 106. It may already have been included in one of the blocks151 at that time, or it may be still waiting in the ordered set 154 inwhich case it will soon be included in a new block 151. AlternativelyTx₀ and Tx₁ could be created and sent to the network 106 together, orTx₀ could even be sent after Tx₁ if the node protocol allows forbuffering “orphan” transactions. The terms “preceding” and “subsequent”as used herein in the context of the sequence of transactions refer tothe order of the transactions in the sequence as defined by thetransaction pointers specified in the transactions (which transactionpoints back to which other transaction, and so forth). They couldequally be replaced with “predecessor” and “successor”, or “antecedent”and “descendant”, “parent” and “child”, or such like. It does notnecessarily imply an order in which they are created, sent to thenetwork 106, or arrive at any given blockchain node 104. Nevertheless, asubsequent transaction (the descendent transaction or “child”) whichpoints to a preceding transaction (the antecedent transaction or“parent”) will not be validated until and unless the parent transactionis validated. A child that arrives at a blockchain node 104 before itsparent is considered an orphan. It may be discarded or buffered for acertain time to wait for the parent, depending on the node protocoland/or node behaviour.

One of the one or more outputs 203 of the preceding transaction Tx₀comprises a particular UTXO, labelled here UTXO₀. Each UTXO comprises avalue specifying an amount of the digital asset represented by the UTXO,and a locking script which defines a condition which must be met by anunlocking script in the input 202 of a subsequent transaction in orderfor the subsequent transaction to be validated, and therefore for theUTXO to be successfully redeemed. Typically the locking script locks theamount to a particular party (the beneficiary of the transaction inwhich it is included). I.e. the locking script defines an unlockingcondition, typically comprising a condition that the unlocking script inthe input of the subsequent transaction comprises the cryptographicsignature of the party to whom the preceding transaction is locked.

The locking script (aka scriptPubKey) is a piece of code written in thedomain specific language recognized by the node protocol. A particularexample of such a language is called “Script” (capital S) which is usedby the blockchain network. The locking script specifies what informationis required to spend a transaction output 203, for example therequirement of Alice's signature. Unlocking scripts appear in theoutputs of transactions. The unlocking script (aka scriptSig) is a pieceof code written the domain specific language that provides theinformation required to satisfy the locking script criteria. Forexample, it may contain Bob's signature. Unlocking scripts appear in theinput 202 of transactions.

So in the example illustrated, UTXO₀ in the output 203 of Tx₀ comprisesa locking script [Checksig P_(A)] which requires a signature Sig P_(A)of Alice in order for UTXO₀ to be redeemed (strictly, in order for asubsequent transaction attempting to redeem UTXO₀ to be valid).[Checksig P_(A)] contains a representation (i.e. a hash) of the publickey P_(A) from a public-private key pair of Alice. The input 202 of Tx₁comprises a pointer pointing back to Tx₁ (e.g. by means of itstransaction ID, TxID₀, which in embodiments is the hash of the wholetransaction Tx₀). The input 202 of Tx₁ comprises an index identifyingUTXO₀ within Tx₀, to identify it amongst any other possible outputs ofTx₀. The input 202 of Tx₁ further comprises an unlocking script <SigP_(A)> which comprises a cryptographic signature of Alice, created byAlice applying her private key from the key pair to a predefined portionof data (sometimes called the “message” in cryptography). The data (or“message”) that needs to be signed by Alice to provide a valid signaturemay be defined by the locking script, or by the node protocol, or by acombination of these.

When the new transaction Tx₁ arrives at a blockchain node 104, the nodeapplies the node protocol. This comprises running the locking script andunlocking script together to check whether the unlocking script meetsthe condition defined in the locking script (where this condition maycomprise one or more criteria). In embodiments this involvesconcatenating the two scripts:

<Sig P _(A) ><P _(A)>∥[Checksig P _(A)]

where “∥” represents a concatenation and “< . . . >” means place thedata on the stack, and “[ . . . ]” is a function comprised by thelocking script (in this example a stack-based language). Equivalentlythe scripts may be run one after the other, with a common stack, ratherthan concatenating the scripts. Either way, when run together, thescripts use the public key P_(A) of Alice, as included in the lockingscript in the output of Tx₀, to authenticate that the unlocking scriptin the input of Tx₁ contains the signature of Alice signing the expectedportion of data. The expected portion of data itself (the “message”)also needs to be included in order to perform this authentication. Inembodiments the signed data comprises the whole of Tx₁ (so a separateelement does not need to be included specifying the signed portion ofdata in the clear, as it is already inherently present).

The details of authentication by public-private cryptography will befamiliar to a person skilled in the art. Basically, if Alice has signeda message using her private key, then given Alice's public key and themessage in the clear, another entity such as a node 104 is able toauthenticate that the message must have been signed by Alice. Signingtypically comprises hashing the message, signing the hash, and taggingthis onto the message as a signature, thus enabling any holder of thepublic key to authenticate the signature. Note therefore that anyreference herein to signing a particular piece of data or part of atransaction, or such like, can in embodiments mean signing a hash ofthat piece of data or part of the transaction.

If the unlocking script in Tx₁ meets the one or more conditionsspecified in the locking script of Tx₀ (so in the example shown, ifAlice's signature is provided in Tx₁ and authenticated), then theblockchain node 104 deems Tx₁ valid. This means that the blockchain node104 will add Tx₁ to the ordered pool of pending transactions 154. Theblockchain node 104 will also forward the transaction Tx₁ to one or moreother blockchain nodes 104 in the network 106, so that it will bepropagated throughout the network 106. Once Tx₁ has been validated andincluded in the blockchain 150, this defines UTXO₀ from Tx₀ as spent.Note that Tx₁ can only be valid if it spends an unspent transactionoutput 203. If it attempts to spend an output that has already beenspent by another transaction 152, then Tx₁ will be invalid even if allthe other conditions are met. Hence the blockchain node 104 also needsto check whether the referenced UTXO in the preceding transaction Tx₀ isalready spent (i.e. whether it has already formed a valid input toanother valid transaction). This is one reason why it is important forthe blockchain 150 to impose a defined order on the transactions 152. Inpractice a given blockchain node 104 may maintain a separate databasemarking which UTXOs 203 in which transactions 152 have been spent, butultimately what defines whether a UTXO has been spent is whether it hasalready formed a valid input to another valid transaction in theblockchain 150.

If the total amount specified in all the outputs 203 of a giventransaction 152 is greater than the total amount pointed to by all itsinputs 202, this is another basis for invalidity in most transactionmodels. Therefore such transactions will not be propagated nor includedin a block 151.

Note that in UTXO-based transaction models, a given UTXO needs to bespent as a whole. It cannot “leave behind” a fraction of the amountdefined in the UTXO as spent while another fraction is spent. Howeverthe amount from the UTXO can be split between multiple outputs of thenext transaction. E.g. the amount defined in UTXO₀ in Tx₀ can be splitbetween multiple UTXOs in Tx₁. Hence if Alice does not want to give Boball of the amount defined in UTXO₀, she can use the remainder to giveherself change in a second output of Tx₁, or pay another party.

In practice Alice will also usually need to include a fee for thebitcoin node 104 that successfully includes her transaction 104 in ablock 151. If Alice does not include such a fee, Tx₀ may be rejected bythe blockchain nodes 104, and hence although technically valid, may notbe propagated and included in the blockchain 150 (the node protocol doesnot force blockchain nodes 104 to accept transactions 152 if they don'twant). In some protocols, the transaction fee does not require its ownseparate output 203 (i.e. does not need a separate UTXO). Instead anydifference between the total amount pointed to by the input(s) 202 andthe total amount of specified in the output(s) 203 of a giventransaction 152 is automatically given to the blockchain node 104publishing the transaction. E.g. say a pointer to UTXO₀ is the onlyinput to Tx₁, and Tx₁ has only one output UTXO₁. If the amount of thedigital asset specified in UTXO₀ is greater than the amount specified inUTXO₁, then the difference may be assigned by the node 104 that wins theproof-of-work race to create the block containing UTXO₁. Alternativelyor additionally however, it is not necessarily excluded that atransaction fee could be specified explicitly in its own one of theUTXOs 203 of the transaction 152.

Alice and Bob's digital assets consist of the UTXOs locked to them inany transactions 152 anywhere in the blockchain 150. Hence typically,the assets of a given party 103 are scattered throughout the UTXOs ofvarious transactions 152 throughout the blockchain 150. There is no onenumber stored anywhere in the blockchain 150 that defines the totalbalance of a given party 103. It is the role of the wallet function inthe client application 105 to collate together the values of all thevarious UTXOs which are locked to the respective party and have not yetbeen spent in another onward transaction. It can do this by querying thecopy of the blockchain 150 as stored at any of the bitcoin nodes 104.

Note that the script code is often represented schematically (i.e. notusing the exact language). For example, one may use operation codes(opcodes) to represent a particular function. “OP_ . . . ” refers to aparticular opcode of the Script language. As an example, OP_RETURN is anopcode of the Script language that when preceded by OP_FALSE at thebeginning of a locking script creates an unspendable output of atransaction that can store data within the transaction, and therebyrecord the data immutably in the blockchain 150. E.g. the data couldcomprise a document which it is desired to store in the blockchain.

Typically an input of a transaction contains a digital signaturecorresponding to a public key P_(A). In embodiments this is based on theECDSA using the elliptic curve secp256k1. A digital signature signs aparticular piece of data. In some embodiments, for a given transactionthe signature will sign part of the transaction input, and some or allof the transaction outputs. The particular parts of the outputs it signsdepends on the SIGHASH flag. The SIGHASH flag is usually a 4-byte codeincluded at the end of a signature to select which outputs are signed(and thus fixed at the time of signing).

The locking script is sometimes called “scriptPubKey” referring to thefact that it typically comprises the public key of the party to whom therespective transaction is locked. The unlocking script is sometimescalled “scriptSig” referring to the fact that it typically supplies thecorresponding signature. However, more generally it is not essential inall applications of a blockchain 150 that the condition for a UTXO to beredeemed comprises authenticating a signature. More generally thescripting language could be used to define any one or more conditions.Hence the more general terms “locking script” and “unlocking script” maybe preferred.

4.3. Side Channel

As shown in FIG. 1 , the client application on each of Alice and Bob'scomputer equipment 102 a, 120 b, respectively, may comprise additionalcommunication functionality. This additional functionality enables Alice103 a to establish a separate side channel 107 with Bob 103 b (at theinstigation of either party or a third party). The side channel 107enables exchange of data separately from the blockchain network. Suchcommunication is sometimes referred to as “off-chain” communication. Forinstance this may be used to exchange a transaction 152 between Aliceand Bob without the transaction (yet) being registered onto theblockchain network 106 or making its way onto the chain 150, until oneof the parties chooses to broadcast it to the network 106. Sharing atransaction in this way is sometimes referred to as sharing a“transaction template”. A transaction template may lack one or moreinputs and/or outputs that are required in order to form a completetransaction. Alternatively or additionally, the side channel 107 may beused to exchange any other transaction related data, such as keys,negotiated amounts or terms, data content, etc.

The side channel 107 may be established via the same packet-switchednetwork 101 as the blockchain network 106. Alternatively oradditionally, the side channel 301 may be established via a differentnetwork such as a mobile cellular network, or a local area network suchas a local wireless network, or even a direct wired or wireless linkbetween Alice and Bob's devices 102 a, 102 b. Generally, the sidechannel 107 as referred to anywhere herein may comprise any one or morelinks via one or more networking technologies or communication media forexchanging data “off-chain”, i.e. separately from the blockchain network106. Where more than one link is used, then the bundle or collection ofoff-chain links as a whole may be referred to as the side channel 107.Note therefore that if it is said that Alice and Bob exchange certainpieces of information or data, or such like, over the side channel 107,then this does not necessarily imply all these pieces of data have to besend over exactly the same link or even the same type of network.

The side channel 107 may comprise a secure channel employing knownsecure communications techniques to enable secure, private off-chaincommunication between parties such as Alice and Bob. For example thesecure channel may be based on a shared secret shared between theparties communicating over the secure channel. Such a channel may beused, for example, to communicate between the verifying party 103V andthe target party 103T, such as to enable the verifying party 103V tosubmit a challenge to a PUF 302/500 held by the target party, and toreceive back the corresponding response.

5. BLOCKCHAIN BASED PUF IDENTITY ATTESTATION

As mentioned in previous sections, response data serving as a record ofa response may be stored on a public blockchain rather than employing atrusted third party system 602. The response data is data determined atset-up, and can later be used by a verifying party 103V (“Bob”) to testan assertion of a target's identity by a target party 103T (“Alice”).Note again that Alice and Bob are just arbitrary labels, and Alice andBob do not necessarily have the same role here as in the generaloverview of blockchain systems given in section 4 (where Bob wasspending the output of a transaction of Alice's).

As discussed previously, the response data for a given CR pair {Ci, Ri}(whether stored on chain or elsewhere) may comprise any of thefollowing, as determined in the set-up phase 702 and stored for futurereference by the verifying party 103V:

-   -   i) an explicit value (either in the clear or encrypted) of the        challenge Ci and/or response Ri, or    -   ii) an explicit value of the response Ri linked to a master        challenge Cm from which the particular challenge Ci for the        respective response Ri can be derived, or    -   iii) an attestation (e.g. hash or double hash) of the response        Ri together with an explicit value of the challenge Ci, or    -   iv) an attestation (e.g. hash or double hash) of the response Ri        linked to a master challenge Cm from which the particular        challenge for the respective response Ri can be derived, or    -   v) a public key of a public-private key pair derived from the        response Ri.

As shown in FIG. 9 , whatever form it takes, in the set-up phase 702such response data 901 can be stored in the output 203 of a transaction152S recorded on a blockchain 150. This may be referred to in thefollowing as a storage transaction. It may be recorded on chain forexample using the techniques discussed in section 4 above, noting againthat Alice in that section is not necessarily the target party 103T andBob in that section is not necessarily the verifying party 103V—in factthe target party 103T, now referred to as Alice, may be the one whoformulates and sends off the storage transaction 152S to be recorded onchain. As another example, the trusted third party may formulate atemplate of the storage transaction for target party 103T to complete byincluding the response data 901 generated at set-up, and then forward tobe recorded on chain. The target part 103T may send the storagetransaction 152S directly to one of the blockchain nodes 104 to bepropagated through the blockchain network 106, or may send it indirectlyvia another party such as the trusted third party. As yet anotherexample, the target party 103T may send his/her response data 901 to thetrusted third party, for the trusted third party to formulate into thestorage transaction 152 and send off to be recorded on chain.

The response data 901 may be stored in an unspendable output of thestorage transaction 152S. E.g. this may be made unspendable by means ofan OP_RETURN, or an OP_FALSE followed by an OP_RETURN, if using theScript protocol (in some blockchain protocols like BTC or BCH, anyinclusion of OP_RETURN makes an output unspendable, whereas in otherslike BSV, both OP_FALSE and OP_RETURN are required to make an outputunspendable). BTC (Bitcoin), BTC (Bitcoin Cash), and BSV (BitcoinSatoshi Vision) are different example implementations of the blockchainsystem described earlier.

Alternatively the response data 901 may be embedded in a spendableoutput of the storage transaction 152S. E.g. this could be keptspendable by including an OP_RETURN without OP_FALSE. As anotherexample, one can embed data in a spendable locking script by includingit immediately before an OP_DROP code. This would apply equally to BTC,BCH and BSV.

In embodiments the response data 901 of a set of multiple different CRpairs {Ci, Ri} of a given target party 103T may be stored. These may bestored in the same output 203 or different outputs 203 of the storagetransaction 152, or a combination of some in the same output and some indifferent outputs. They may be stored in the same storage transaction152S, or the response data 901 of different CR pairs may be stored indifferent storage transactions 152S, or a combination of some in thesame transaction and some in different transactions.

Note that the on-chain storage is not necessarily limited to anaccount-based model. In alternative deployments, the response data 901could be stored in one or more smart contracts of one or moretransactions of an account-based model.

In the verification phase 704, when the verifying party 103V wishes toverify the identity of the target, then he/she accesses the blockchain150, in order to obtain the response data 901 corresponding to one aparticular CR pair from a storage transaction 152S. In embodiments thisgives the verifying party 103V the response Ri corresponding to aparticular challenge Ci, or the attestation (e.g. hash or double hash)of that response Ri. The verifying party 103V also submits the challengeCi to the target party 103V, and in response receives back the(purported) response R′i which the target party 103T (or their device)generates by inputting the received challenge Ci to the PUF module 603.The verifying party 103V then compares the returned response R′i withthe version retrieved from the storage transaction 152S on chain, orapplies the same transformation (e.g. H(R′i) or H²(R′i)) to the receivedresponse that was used for the attestation and compares this with theattestation that was retrieved from the storage transaction 152S onchain. Either way, if the comparison gives a match, the target isverified.

The verifying party 103V may access the blockchain 150 via one of thenodes 104 of the blockchain network 106, or alternatively by obtainingthe response data from any external party, who may also provide a Merkleproof of inclusion of that data (i.e. the transaction) in theblockchain.

In embodiments where the response data 901 is stored on a public mediumsuch as a blockchain 150, it may be desirable that the actual responsevalue Ri itself is not disclosed publicly or unrestrictedly. Otherwiseany malicious party can view the Ri on chain and then pretend to be thetarget party 103T if challenged with Ci. Instead therefore, it may bepreferred to store only the attestation of Ri (e.g. H(Ri) or H²(Ri)) asthe response data 901 held on chain, or else to store the explicit valueof Ri but in encrypted form. Or in some cases the attestation could bestored on chain in encrypted form.

In the case where there are potentially multiple verifying parties,storing Ri or the attestation thereof in encrypted form enables thetarget party 103T or trusted third party to control which verifyingparties 103V are able to obtain the storage data 901 corresponding towhich of CR pairs. This may be achieved by only giving the decryptionkey for a certain piece of response data 901 to a given verifying party,and giving the decryption key for another piece of response data 901only to another verifying party. The distribution of the decryption keyscould be administered by the target party 103T or the trusted thirdparty. Each verifying party or subset of verifying parties is giventheir own subset of one or more decryption keys for accessing arespective subset of the pieces of response data 901 (e.g. CR pairs).Preferably the subsets are exclusive of one another. However in otherimplementations they could overlap (e.g. different groups within thesame organization could have access to overlapping subsets of CR pairs).

As a variant of this if response data 901 (e.g. CR pairs) are stored ina third party system 602 instead of on-chain, then instead of (or aswell as) distributing decryption keys, other means may be employed toensure each verifying party only gets access to their own subset of CRpairs (or more generally response data). E.g. the trusted third partysystem 602 may maintain a password protected account for each verifyingparty, which they are required to log into to gain access to theirchallenge(s) and which only gives them access to their own CR pair(s).

Such schemes may be advantageous for security. If a response Ri of agiven CR pair is to be disclosed to one verifying party 103V, it may bedesirable that the same CR pair is not used for another verifying party103V. Otherwise the first verifying party 103V could use the now-knownresponse Ri to pretend to another verifying party that he/she is thetarget party 103T. However, taking steps to prevent this is notessential if all the potential verifying parties 103V with access to theresponse data 901 are trusted.

In further variants, the response data 901 stored on chain could takethe form of a public key of the target party 103T, being a public key ofa public-private key pair generated at set-up based on a correspondingresponse Ri (e.g. using it as a seed). In this case the verifying party103V accesses the public key from the storage transaction 152S and usesit to verify a message signed by the target party 103T with thecorresponding private key. In some cases the public keys could be storedon chain in encrypted form so that different public keys can beallocated for use by different verifying parties 103V.

As also shown in FIG. 9 , in embodiments that employ an output (e.g.UTXO-based) model, then this may be exploited to provide an efficientmechanism for managing CR pairs (or keys derived therefrom). Managinghere may comprise updating or revoking a CR pair or key, e.g. once ithas already been consumed (used in a verification).

To do this, a new modifier transaction 152M is recorded on theblockchain 150. It has an input 202 which points to one of the outputs203 of the storage transaction 152S in which the piece of response data901 to be revoked or updated is stored. This may be referred to as“spending”, “redeeming” or “assigning” that output (though note thatthis does not necessarily imply the transfer of monetary value). This isunderstood at the level of a layer-2 protocol recognized by theverifying party 103V to mean that the response data 901 in thepointed-to storage transaction 152S or output 203 is no longer to beused. If the modifier transaction 152M itself contains response data901′ in one of its own outputs, this is taken to represent that the newresponse data 901′ represents replacement of the previous response data901 (e.g. a new CR pair). If the verifying party accesses the blockchain150 to find response data to use in a verification operation, it willuse the updated version 901′ rather than the replaced version. If on theother hand the modifier transaction 152U does not contain replacementresponse data 901, then it is taken to simply revoke the response data901 in the storage transaction 152S or output 203 to which it points.

In some embodiments, the response data 901 is embedded in a spendableoutput of the storage transaction 152S, and may be revoked or updated byspending (i.e. assigning or redeeming) the particular output 203 inwhich the response data 901 (e.g. CR pair) is stored. In some suchembodiments, different pieces of response data 901 corresponding todifferent CR pairs may be stored in individual outputs 203 of the samestorage transaction 203 and individually evoked or updated.

In other embodiments, the response data 901 is stored in an unspendableoutput of the storage transaction 152S, and may be revoked or updated byspending (i.e. assigning or redeeming) a different, spendable output ofthe storage transaction 152S. In some such embodiments, multiple piecesof storage data 901 corresponding to multiple different CR pairs (storedin the same or different unspendable outputs) may be revoked or updatedby spending the same spendable output of the same transaction 152S.

As an example use case, the record of a piece of response data 901,corresponding to a CR pair, may be revoked or updated once it has beenconsumed, i.e. used in a verification. This could apply whether theresponse data 901 is an explicit record of Ri, or an attestation, or apublic key derived from Ri. Either way, this may be advantageous forsecurity reasons, so that response data which has now been released intothe world is no longer usable again.

The modifier transaction 152M could be formulated and sent to berecorded on chain by the target party 103T. It could be sent eitherdirectly to a blockchain node 104 to propagate, or indirectly to a node104 via an intermediate party. Alternatively the trusted third party maysend a template transaction for the target party to complete (e.g. bysigning and/or adding replacement response data 901′) and then forwardon to a node 104, either directly or indirectly, to be recorded onchain. As another possibility, the trusted third party could formulatethe modifier transaction 152M (possibly based on a template or some datasent from the target part 103T, e.g. comprising replacement responsedata 901′), and then the trusted third party may send the modifiertransaction 152M to a node 104 to be recorded on chain. Note that all ofthese options may also apply to the way in which the storage transaction152S is recorded on the blockchain 150 as well.

According to the various concepts discussed above, there is thusprovided a system for i) linking an identity (or other relatedinformation, such as a public key) to a UTXO, and using the spend-stateof this UTXO as a proxy for the validity of the identity credentials;and ii) establishing a set of transactions to perform efficientidentity-management operations, such as setup, revocation, update andverification. The process is more efficient in that the number ofcommunications is reduced, as all parties can consult the blockchain tosee when CRPs are consumed or identities revoked, rather than allparties needing to communicate with each other all the time.

Such techniques may be used for example to extend the framework forlinking identity to PUF devices, as presented previously, by minimisingthe reliance on a third-party KYC (know your customer) provider forhandling CRP data used in verification. This goal may be achieved bypartially replacing the role, or rather some of the functions, of a KYCprovider with a public blockchain, whereby a user may instantiate theirown identity credentials, related to an ePUF device, independently ofany third party.

The role of the trusted-third party in an identity system is notnecessarily eschewed completely, but either way, the process of identitymanagement may be improved such that their involvement in the process,and related burden placed on them, is at least reduced.

5.1. Linking PUF Identity to a UTXO Set

The first aspect whereby the use of a blockchain can improve on theidentity systems, such as those discussed in previous sections, is byusing the unspent transaction output set (UTXO set) of a publicblockchain to manage CRPs relating to a PUF identity.

In this section, two distinct example mechanisms are disclosed formapping CRPs to members of the UTXO set, and using their status as‘spent’ or ‘unspent’ state as an indication of whether each particularCRP has been consumed in an identity verification process. The firstmechanism involves embedding CRP data in spendable UTXOs, and the secondinvolves pairing them to spendable UTXOs. In either case, additionaldata related to the CRPs, or the identity in question, may also beoptionally included in the system.

5.1.1. Embedding in spendable UTXOs: The first mechanism is to bind CRPsto spendable UTXOs, which are transaction outputs containing scriptswhose conditions can be satisfied by future inputs, and therefore can beconsumed by future spending transactions. There are many differentoptions for implementing such an embedding, but for our purposes thiswill generally consist at least of the following locking script:

[Checksig P] OP_RETURN<Rep(C,R)>

where [Checksig P] is a standard pay-to-public-key-hash (P2PKH) lockingscript, and Rep(C, R) is a representation of a particularchallenge-response pair (C, R).

This locking script can be unlocked simply by providing a validsignature Sig P over a spending transaction, where the signature isconsidered valid against the public key P. It should be noted that anydata that follows the opcode OP_RETURN will not be considered whenvalidating a spending transaction, and therefore this data may betreated as arbitrary and unformatted with respect to blockchainvalidators.

The data following the OP_RETURN code in the script above is arepresentation Rep(C, R) of the challenge-response pair (C, R). Thisrepresentation could be made in various ways, depending on the use casein question. However, a sensible example would be to encrypt the CRPusing a key k known only to the prover Alice who owns the PUF. In thiscase, we could have any of the following representations:

Rep(C,R)=Encrypt(C,k),

Rep(C,R)=Encrypt(R,k),

Rep(C,R)=Encrypt(C∥R,k).

These representations would allow Alice to retrieve or prove, at a latertime, either the challenge, response, or CRP respectively that wasincluded in her UTXO.

Additional script encumbrances: It is possible to extend the basiclocking script shown previously to include additional conditions on theinput script that spends the output in the future. A sensible example ofsuch an extra condition would be the following script:

[Checksig P][Hash Puzzle H ²(R)] OP_RETURN<Rep(C,R)>

where [Hash Puzzle H²(R)]=OP_HASH160<H(R)>OP_EQUAL. Note that other hashfunction opcodes may be used. This modified script now requires thespender to reveal the hash of the challenge R in addition to providing avalid signature for the public key P. The idea here is that, in somescenarios, this can be used a knowledge proof that the spender knows theinformation H(R) that is in turn related to the challenge in question R.

Transaction models: Given that the exact structure of the transactionlocking scripts to be used has been decided, the choice can then be madeas to how to structure transactions containing these scripts as a way toattest store, attest to and manage CRPs.

It is disclosed herein to map CRPs, and the associated locking scripts,to UTXOs in a one-to-one manner. In other words, every UTXO containingsuch a script will correspond to exactly one CRP relating to aparticular PUF device.

There are then a few options as to how to organise these UTXOs intotransactions. The most likely possible options are as follows:

-   -   1. One CRP per transaction.    -   2. One CRP set per transaction.    -   3. One PUF per transaction.

The first option may be applicable in some cases, such as for PUFs thatare very infrequently used, such as for updating a will, and has thebenefit that multiple CRPs are not obviously linked with one another.This may be useful also in situations where extreme privacy is required,as the consumption and revelation of one CRP can be revealedindependently of any others.

The transaction in Table 1 below is an example implementation of thefirst option. It can be seen that the transaction comprises only asingle input and output, and therefore each CRP will be contained indifferent transaction. When its output is spent, the relevance of thistransaction to the identity system is effectively ended, other than forauditing purposes.

TABLE 1 single CRP mapped to a UTXO in single transaction.TxID_(CRP-Single) Input Output Outpoint Script Value Script TxID_(Prev)<SIG_(A)> x BSV [Checksig P_(A) ¹] <P_(A)> OP_RETURN <Rep(C₁, R₁)>

The second option, whereby many CRPs are each mapped to respective UTXOsin a single transaction, may be more desirable for a use case such asbank cards where the expected frequency of CRP-consumption isconsiderably higher. The transaction in Table 2 below shows how this canbe achieved.

Note that the input signature, which would likely have been generated byAlice, can be made to sign over the entire set of outputs. This providesa one-to-many linkage from one public key P_(A) to many UTXOs, and hencemany CRPs, whilst maintaining a one-to-one mapping of UTXOs to distinctCRPs themselves. It is also assumed that each output/CRP has its ownassociated public key (all owned by Alice) to avoid reuse.

TABLE 2 a set of CRPs mapped to respective UTXOs of a single transactionTxID_(CRP-Set) Input Output Outpoint Script Value Script TxID_(Prev) <SIG_(A) > x BSV [Checksig P_(A) ¹] OP_RETURN < P_(A) > <Rep(C₁, R₁)> xBSV [Checksig P_(A) ²] OP_RETURN <Rep(C₂, R₂)> x BSV [Checksig P_(A) ³]OP_RETURN <Rep(C₃, R₃)> . . . x BSV [Checksig P_(A) ^(n)] OP_RETURN<Rep(C_(n), R_(n))>

The option shown above can also be integrated well with embodiments thatupdate CRP sets over time, where each time an updated set is generated,a new transaction can be issued for that set. In addition, one can alsogenerate and issue multiple different CRP sets for the same PUF at thesame time, via parallel independent (i.e. not related on-chain)transactions. This may be useful for establishing identity with multipledifferent trusted-third parties (e.g. different banks) such that theidentities are both independently established but are still anchored bythe same PUF.

The third option, wherein a single transaction is used to represent asingle PUF, is simply a more restrictive version of option 2, whereupdates are not possible. This may be applicable for cases where aPUF-containing device is given a particular ‘lifespan’, where it canonly be used for a pre-determined number of authentications before auser is issued with a new device.

5.1.2. Pairing with Spendable UTXOs

An alternative to embedding CRPs within spendable UTXOs is to simplypair them with these outputs. In this case, a difference from theexisting work on digital certificates is that the transaction may beconstructed and signed by Alice, as she may wish to attest to anidentity independently of any third-party.

TABLE 3 A transaction containing spendable UTXOs mapped to CRPs.TxID_(CRP-Set) Input Output Outpoint Script Value Script TxID_(Prev) <SIG_(A) > < P_(A) > x BSV OP_DUP OP_HASH160 < P_(A) ¹ > OP_EQUALVERIFYOP_CHECKSIG 0 BSV OP_0 OP_RETURN <Rep(C₁, R₁)> x BSV OP_DUP OP_HASH160 <P_(A) ² > OP_EQUALVERIFY OP_CHECKSIG 0 BSV OP_0 OP_RETURN <Rep(C₂, R₂)>... x BSV OP_DUP OP_HASH160 < P_(A) ^(n) > OP_EQUALVERIFY OP_CHECKSIG 0BSV OP_0 OP_RETURN <Rep(C_(n), R_(n))>

In the diagram above can be seen an example transaction containing 2noutputs relating to n CRPs, whereby each spendable output can be mappedto one of the CRPs, and the CRP representation itself has been includedin a corresponding unspendable output (e.g. OP_FALSE OP_RETURN). Itshould also be noted that the three possible variants for organising theCRPs into transactions and UTXOs apply similarly here.

5.1.3. Discussion

Benefits to CRP-management: the concept of mapping CRPs to UTXOs cansignificantly improve CRP management and handling for users of theidentity protocols from the previous sections. An advantage is that onecan partly offload the storage and lookup of CRPs to the blockchainnetwork 106, and service providers who can facilitate reliable retrievalfrom it.

By mapping all of the ‘live’ CRPs of a particular PUF to UTXOs, it ispossible to improve the CRP update process by querying the state of theUTXO set for accurate information about the CRPs currently available toa given PUF in an identity system.

An example of a simple process utilising the blockchain and the UTXO-CRPmapping conventions we have described is as follows:

-   -   1. Alice obtains a PUF device and enumerates a set of CRPs as        (C₁, R₁), (C₂, R₂), . . . , (C_(n), R_(n)).    -   2. Alice generates a transaction TxID_(CRP)-Set as shown in        Table 2 and broadcasts to the blockchain network.    -   3. Alice consumes multiple CRPs over time to authenticate her        identity with a third party.    -   4. Alice now wishes to check if she has enough CRPs to cover her        expected activities for the coming week:        -   1. Alice queries a blockchain node 104, or SPV-like service            provider, asking which UTXOs of TxID_(CRP)-Set are currently            unspent.        -   2. The blockchain node or service provider responds with the            number of outputs of the transaction TxID_(CRP)-Set that are            still unspent.    -   5. If the returned number is insufficient, Alice can perform an        identity update process with her trusted-third party, or simply        enumerate more CRPs for independently-established identity.        Otherwise, Alice takes no action.

Embedding versus pairing: the choice of whether to embed CRPs withinspendable outputs or to simply pair them with the outputs gives Alicethe choice between two different benefits that distinguish these cases.

If the CRPs are embedded within spendable outputs, this incentivises theblockchain nodes 104, who maintain the blockchain network 106, to keepthe data of these outputs readily available. This means that theresponses to Alice's queries may be faster and, more crucially, theblockchain nodes are more likely to be able to serve the raw data ofthese transaction outputs back to Alice.

If, as previously discussed, the representation Rep(C, R) of the CRP isincluded such that it contains the raw (or obfuscated) data of achallenge, response or both, then this means Alice will be able toretrieve the relevant information from the blockchain network 106. Thisallows Alice to replace local storage, and operate a more lightweightsystem with the blockchain 150, as the embedding of the data inspendable outputs increases the likelihood that her data will have highavailability regardless.

By contrast, if the CRPs are only paired with spendable outputs, thenAlice may only be able to determine how many CRPs are available to her,but not necessarily retrieve the representation data itself from Bitcoinnodes. This may mean that Alice has to consult an agent outside of theblockchain node network 106 if she does not maintain her CRP setlocally.

Using double-hashes: in the example implementations above, it is shownthat the double-hash H²(Data) can be used as an on-chain representationof some Data. The reason for using the double-hash in this manner isthat it allows the single-hash to also be revealed on-chain, acting inprinciple like a knowledge proof that a party knows H(Data), which is inturn connected to the Data.

This may be useful for example in a PUF-identity situation where H²(R)is recorded on-chain by Alice as a spending encumbrance that can besatisfied by a third-party providing H(R), given that Alice has sharedthe actual value of R with them.

Multi-party signing: it is also plausible that the transactions detailedin this section may include more signatures, from multiple differentparties, to aid in Alice's attestation of the PUF identity. For example,it may desirable for both Alice and a third-party identity provider tosign the input(s) of the CRP transactions as a method to improve thetrust of a verifier in Alice's identity. This is particularly relevantif the counter-signer is certificate authority that can attest toAlice's public key(s) used for signing blockchain transactions. Multipleparties may be included the signing process for example by means ofthreshold signatures or key-splitting techniques (e.g. Shamir SecretSharing), as an alternative to just multiple signatures (i.e.‘multi-sig’).

5.2. Efficient Identity-Management Using Transactions

An additional way in which a blockchain may be used in conjunction withPUF-based identity systems, such as those presented previously, is as anefficient means to revoke an identity key or token secured by a PUFdevice.

In prior work done on digital certificate management, it is known toissue and revoke certificates on-chain, and a corresponding certificateverification process accompanies this.

Consider a scenario whereby Alice is happy to cooperate with acertificate authority when attesting to her PUF-based identity on-chain.The process for Alice to register a certificate for her identityon-chain is as follows:

-   -   1. The certificate authority (CA) verifies the identity of        Alice.    -   2. The CA creates the certificate transaction. This transaction        has the following inputs and outputs:        -   a. Input: CA's UTXO with an unlocking script containing CA's            signature and public key.        -   b. Output 1: a P2PKH locking script.        -   c. Output 2: an OP_RETURN output containing Alice's public            key.    -   3. The transaction is broadcast, and once it is mined, the CA        provides Alice with the transaction ID TXID_(CTX-PK) _(A) .

This process culminates in Alice and the certificate authoritycooperating to produce a transaction which signed by the CA, containsone unspendable output including a certificate on Alice's public key,and a spendable output paired to the certificate that the CA can use torevoke the certificate.

Embodiments disclosed herein use a hybrid of the method outlined for thedigital certificates above and a method of establishing PUF-basedidentity, such as one of the methods described earlier. An element addedto the PUF identity system here is for the generic trusted third-party(analogous to the CA), to be able to ‘revoke’ a CRP, or a related publickey, by spending a UTXO.

The case where the trusted third-party revokes a certificate on Alice'spublic key relates to the cryptographic identity establishment discussedearlier.

In the case of CR-pairs (CRPs) stored or attested to on chain,embodiments disclosed herein provide a scheme that allows for thetrusted third-party to revoke CRPs once they are used in anauthentication process. An example method is as follows:

-   -   1. Alice and the trusted third-party conduct an identity setup        protocol (e.g. as described earlier).    -   2. Alice and the trusted third-party now wish to use the        blockchain for management of the CRPs generated in 1, or that        are now obtainable after step 1:        -   a. Alice creates a CRP mapping transaction TxID_(CRP-Set)            which maps the CRPs to transaction outputs. This is shown in            Table 4 below.        -   b. Alice and the trusted third-party both sign            TxID_(CRP-Set)    -   3. The CRP mapping transaction TxID_(CRP-Set) is broadcast and        published in a blockchain block.

TABLE 4 a CRP mapping transaction allowing CRP revocation/consumption bythe trusted third-party TxID_(CRP-Set) Input Output Outpoint ScriptValue Script TxID_(Prev) < SIG_(A) > < P_(A) > x BSV [Checksig P_(TTP)]< SIG_(TTP) > OP_RETURN <Rep(C₁, R₁)> < P_(TTP) > x BSV [ChecksigP_(TTP) ] OP_RETURN <Rep(C₂, R₂)> x BSV [Checksig P_(TTP)] OP_RETURN<Rep(C₃, R₃)> ... x BSV [Checksig P_(TTP) ] OP_RETURN <Rep(C_(n),R_(n))>

The mapping transaction created in this process is shown in Table 4above. This is very similar to the CRP mapping transaction shownpreviously in Table 2, with a difference that both the trusted thirdparty and Alice sign the input, and that each of the UTXOs mapped to theCRPs can be revoked by the trusted third-party by spending in a futuretransaction.

This is advantageous as it allows for the revocation of CRPs to behandled without direct communication, and the TTP may perform revocationon the user's behalf, which further reduces the burden on Alice in thesystem and allows her identity management to become even morelightweight.

6. CONCLUSION

Other variants or use cases of the disclosed techniques may becomeapparent to the person skilled in the art once given the disclosureherein. The scope of the disclosure is not limited by the describedembodiments but only by the accompanying claims.

For instance, some embodiments above have been described in terms of abitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104.However it will be appreciated that the bitcoin blockchain is oneparticular example of a blockchain 150 and the above description mayapply generally to any blockchain. That is, the present invention is inby no way limited to the bitcoin blockchain. More generally, anyreference above to bitcoin network 106, bitcoin blockchain 150 andbitcoin nodes 104 may be replaced with reference to a blockchain network106, blockchain 150 and blockchain node 104 respectively. Theblockchain, blockchain network and/or blockchain nodes may share some orall of the described properties of the bitcoin blockchain 150, bitcoinnetwork 106 and bitcoin nodes 104 as described above.

In preferred embodiments of the invention, the blockchain network 106 isthe bitcoin network and bitcoin nodes 104 perform at least all of thedescribed functions of creating, publishing, propagating and storingblocks 151 of the blockchain 150. It is not excluded that there may beother network entities (or network elements) that only perform one orsome but not all of these functions. That is, a network entity mayperform the function of propagating and/or storing blocks withoutcreating and publishing blocks (recall that these entities are notconsidered nodes of the preferred bitcoin network 106).

In other embodiments of the invention, the blockchain network 106 maynot be the bitcoin network. In these embodiments, it is not excludedthat a node may perform at least one or some but not all of thefunctions of creating, publishing, propagating and storing blocks 151 ofthe blockchain 150. For instance, on those other blockchain networks a“node” may be used to refer to a network entity that is configured tocreate and publish blocks 151 but not store and/or propagate thoseblocks 151 to other nodes.

Even more generally, any reference to the term “bitcoin node” 104 abovemay be replaced with the term “network entity” or “network element”,wherein such an entity/element is configured to perform some or all ofthe roles of creating, publishing, propagating and storing blocks. Thefunctions of such a network entity/element may be implemented inhardware in the same way described above with reference to a blockchainnode 104.

It will be appreciated that the above embodiments have been described byway of example only. More generally there may be provided a method,apparatus or program in accordance with any one or more of the followingStatements.

-   -   Statement 1. A computer-implemented method for enabling one or        more verifying parties to verify an identity of a target        comprising a target party or device of the target party; the        method comprising, in a set-up phase:        -   storing, in a data store, a respective piece of response            data for each of a set of one or more responses resulting            from a setting-up party inputting a respective set of one or            more challenges into a PUF module comprising a physically            unclonable function, PUF, to generate the one or more            responses based on the PUF; and        -   storing an indication of the set of challenges in the data            store, wherein the indication does not comprise a value of            each of the challenges in the set, but rather a master            challenge from which the set of challenges is derivable by            applying a derivation function to the master challenge;        -   thereby making at least one of the pieces of response data            and the respective master challenge available to the one or            more verifying parties for verifying the identity of the            target in a subsequent verification phase, wherein the            respective piece of response data for each response            comprises the respective response or data derived therefrom.    -   Statement 2. The method of Statement 1, wherein the data store        is implemented in third party computer equipment.    -   Statement 3. The method of Statement 1 or 2, wherein the method        is performed by a trusted third party.    -   Statement 4. The method of Statement 3 as dependent on Statement        2, wherein the third party computer equipment is computer        equipment of the trusted third party.    -   Statement 5. The method of Statement 3 or 4, wherein the        setting-up party is the target party, the method comprising        receiving the set of responses or pieces of response data from        the target party, and the storing comprising storing the pieces        of response data in the data store based on the receiving from        the target party.    -   Statement 6. The method of Statement 5, comprising an initial        step of generating and sending the set of challenges or master        challenge to the target party to enable the target party to        generate the set of responses.    -   Statement 7. The method of Statement 5, wherein the set of        challenges is generated by the target party and the method        comprises receiving the set of challenges or the master        challenge from the target party in order to store the master        challenge in the data store.    -   Statement 8. The method of Statement 2 or any subsequent        Statement as dependent thereon, wherein the setting-up party is        the target party, and the method is performed by the target        party, the target party performing said storing of the pieces of        response data and master challenge by submitting the set of        responses or pieces of response data, and the master challenge,        to the third party computer equipment.    -   Statement 9. The method of Statement 7 or 8, comprising        establishing a secure channel between the target party and        trusted third party based on a shared secret shared between the        target party and trusted third party, wherein the receiving or        submitting of the master challenge or set of challenges between        the target party and trusted third party is performed over the        secure channel.    -   Statement 10. The method of Statement 9, wherein said submitting        comprises sending the set of responses or pieces of response        data to the third party system over a network.    -   Statement 11. The method of Statement 3 or any subsequent claim        as dependent thereon, wherein the setting-up party is the        trusted third party who performs the set-up on behalf of the        target party, then sends the PUF module to the target party to        enable the target party to respond to challenges from the one or        more verifying parties.    -   Statement 12. The method of Statement 1 or 2, wherein the data        store is a public peer-to-peer publication medium.    -   Statement 13. The method of Statement 12, wherein the        peer-to-peer publication medium is a blockchain.    -   Statement 14. The method of any preceding Statement, wherein the        master challenge comprises identification data comprising, or        derived from, one or more pieces of identification information        relating to the identity of the target.    -   Statement 15. The method of Statement 14, wherein the        identification data comprises, or is generated from, a        combination of a plurality of pieces of identification        information of the target party.    -   Statement 16. The method of Statement 14 or 15, wherein the        method is performed by a trusted third party, and comprises        determining the master challenge data based on obtaining the one        or more pieces of identification information.    -   Statement 17. The method of Statement 16, wherein said obtaining        comprises receiving the one or more pieces of identification        information from the target party.    -   Statement 18. The method of Statement 14 or 15, wherein the        method is performed by the target party, and the storing of the        master challenge comprises the target party performing one of:        determining the master challenge and sending it to be stored in        the data store, or sending at least one of the one or more        pieces of identification information to a trusted third party to        cause the trusted third party to generate the master challenge        and it store in the data store.    -   Statement 19. The method of Statement 17 or 18, comprising        establishing a secure channel between the target party and        trusted third party based on a shared secret shared between the        target party and trusted third party, wherein the receiving or        sending of the identification information between the target        party and trusted third party is performed over the secure        channel.    -   Statement 20. The method of any preceding Statement, wherein the        target is one of multiple targets for which the data store        stores corresponding sets of response data and master        challenges, each master challenge enabling derivation of a        respective set of challenges, for use in verifying the        corresponding target.    -   Statement 21. The method of Statement 20, wherein each master        challenge comprises identification data of the corresponding        target.    -   Statement 22. The method of any preceding Statement, wherein the        derivation function derives the set of challenges in an ordered        form, and each of the pieces of response data is stored in        association with an identifier specifying a different one of the        challenges in said order, thus mapping different respective        pieces of response data to different respective ones of the set        of challenges derivable from the master challenge.    -   Statement 23. The method of any preceding Statement, wherein the        challenges of the set are derivable in a chained manner, a first        of the set of challenges being derivable by applying the        derivation function to the master challenge, and each successive        challenge in said set being derivable by applying the derivation        function to a preceding challenge in the set.    -   Statement 24. The method of any of Statements 1 to 22, wherein        the challenges of the set are derivable in a hierarchical        manner, a first subset of the set of challenges being derivable        by applying the derivation function to the master challenge, and        each of one or more successive subsets being derivable by        applying the derivation function to one of the challenges        further back in the hierarchy.    -   Statement 25. The method of any preceding Statement, wherein the        derivation function or an indication thereof is also stored in        the data store, thereby making the derivation function or        indication thereof available to the one or more verifying        parties.    -   Statement 26. The method of any preceding Statement, wherein the        derivation function is pre-known to at least one of the        verifying parties and does not need to be made available or        indicated to the at least one verifying party.    -   Statement 27. The method of any preceding Statement, wherein the        one or more verifying parties are a plurality of verifying        parties.    -   Statement 28. The method of any preceding Statement, wherein the        set of challenges is a plurality of challenges, and the set of        responses is respective plurality of responses.    -   Statement 29. The method of Statement 28, wherein the storing        makes only a respective subset of one or more of the pieces of        response data available to each of the verifying parties, with        different subsets being made available to different ones of the        verifying parties.    -   Statement 30. The method of Statement 29, wherein the subsets        are exclusive of one another.    -   Statement 31. The method of any preceding Statement, wherein        each of the response data records comprises an explicit value of        the respective response.    -   Statement 32. The method of Statement 31, wherein the values of        the response data records are stored in the data store only in        encrypted form.    -   Statement 33. The method of Statement 32, wherein each of a        plurality of subsets of one or more of the response data records        is individually encrypted, each subset requiring a different        respective decryption key to decrypt.    -   Statement 34. The method of Statement 33 as dependent on at        least Statement 29, wherein the different subsets are made        available to different ones of the verifying parties by        distributing different ones of the decryption keys to different        verifying parties.    -   Statement 35. The method of any of Statement 1 to 30, wherein        each of the pieces of response data comprises only an        attestation of the respective response, not an explicit value of        the response, the attestation comprising a transformation of the        respective response which does not disclose the response, but        which enables a verifying party to verify the identity of the        target by performing the same transformation on a further        instance of the respective response returned by the target and        comparing with the attestation.    -   Statement 36. The method of Statement 35, wherein the        transformation comprises a hash or double hash.    -   Statement 37. The method of any preceding Statement, wherein the        PUF module comprises a PUF, interface logic, and a deterministic        transform function; wherein the interface logic causes the        generation of the set of responses by: receiving the set of        challenges; inputting a base challenge into the PUF to generate        a corresponding primary response; and inputting each of the        received set of challenges and into the transform function in        conjunction with the generated base response in order to        generate the respective response of said set of responses, the        transform function being a function of the respective challenge        from the received set and the generated base response.    -   Statement 38. Computer equipment comprising: memory comprising        one or more memory units; and processing apparatus comprising        one or more processing units, wherein the memory stores code        arranged to run on the processing apparatus, the code being        configured so as when on the processing apparatus to perform the        method of any preceding Statement.    -   Statement 39. A computer program embodied on a non-transitory        computer-readable medium and configured so as, when run on one        or more processors, to perform the method of any of Statement 1        to 37.    -   Statement 40. A computer-implemented method whereby a verifying        party verifies an identity of a target comprising a target party        or device of the target party; the method comprising, by the        verifying party: accessing, from a data store, a piece of        response data from among a set of response data records, each        comprising either: a) a value of a response resulting from        inputting a challenge into a PUF module comprising a physically        unclonable function, PUF, associated with the target, or b) an        attestation comprising a transformation of the response;        accessing a master challenge from the data store, and deriving        at least one of the set of challenges by applying a derivation        function to the master challenge; sending to the target a        request comprising the at least one challenge to the target, and        in response receiving back a further instance of the response;        performing a comparison and verifying the identity of the target        on condition that the comparison results in a match, wherein the        comparison comprises: in the case of a) the stored value of the        response matches the further instance, or in the case of b) the        attestation matches the same transformation applied to the        further instance.    -   Statement 41. The method of Statement 40, wherein the applying        of the derivation function comprises applying the derivation        function at computer equipment of the verifying party.    -   Statement 42. The method of Statement 40, wherein the data store        is implemented at third party computer equipment, and the        applying of the derivation function comprises the verifying        party requesting the derivation function to be applied at the        third party computer equipment.    -   Statement 43. Computer equipment comprising: memory comprising        one or more memory units; and processing apparatus comprising        one or more processing units, wherein the memory stores code        arranged to run on the processing apparatus, the code being        configured so as when on the processing apparatus to perform the        method of Statement 40, 41 or 42.    -   Statement 44. A computer program embodied on a non-transitory        computer-readable medium and configured so as, when run on one        or more processors, to perform the method of Statement 40, 41 or        42.

1. A computer-implemented method for enabling one or more verifying parties to verify an identity of a target comprising a target party or device of the target party; the method comprising, in a set-up phase: storing, in a data store, a respective piece of response data for each of a set of one or more responses resulting from a setting-up party inputting a respective set of one or more challenges into a PUF module comprising a physically unclonable function, PUF, to generate the one or more responses based on the PUF; and storing an indication of the set of challenges in the data store, wherein the indication does not comprise a value of each of the challenges in the set, but rather a master challenge from which the set of challenges is derivable by applying a derivation function to the master challenge; thereby making at least one of the pieces of response data and the respective challenge available to the one or more verifying parties for verifying the identity of the target in a subsequent verification phase, wherein the respective piece of response data for each response comprises the respective response or data derived therefrom.
 2. The method of claim 1, wherein the data store is implemented in third party computer equipment. 3-11. (canceled)
 12. The method of claim 1, wherein the data store is a public peer-to-peer publication medium, wherein the peer-to-peer publication medium is a blockchain.
 13. (canceled)
 14. The method of claim 1, wherein the master challenge comprises identification data comprising, or derived from, one or more pieces of identification information relating to the identity of the target.
 15. The method of claim 14, wherein the identification data comprises, or is generated from, a combination of a plurality of pieces of identification information of the target party.
 16. The method of claim 14, wherein the method is performed by a trusted third party, and comprises determining the master challenge data based on obtaining the one or more pieces of identification information.
 17. The method of claim 16, wherein said obtaining comprises receiving the one or more pieces of identification information from the target party.
 18. The method of claim 14, wherein the method is performed by the target party, and the storing of the master challenge comprises the target party performing one of: determining the master challenge and sending it to be stored in the data store, or sending at least one of the one or more pieces of identification information to a trusted third party to cause the trusted third party to generate the master challenge and it store in the data store.
 19. The method of claim 17, comprising establishing a secure channel between the target party and trusted third party based on a shared secret shared between the target party and trusted third party, wherein the receiving or sending of the identification information between the target party and trusted third party is performed over the secure channel.
 20. The method of claim 1, wherein the target is one of multiple targets for which the data store stores corresponding sets of response data and master challenges, each master challenge enabling derivation of a respective set of challenges, for use in verifying the corresponding target.
 21. The method of claim 20, wherein each master challenge comprises identification data of the corresponding target.
 22. The method of claim 1, wherein the derivation function derives the set of challenges in an ordered form, and each of the pieces of response data is stored in association with an identifier specifying a different one of the challenges in said order, thus mapping different respective pieces of response data to different respective ones of the set of challenges derivable from the master challenge.
 23. The method of claim 1, wherein the challenges of the set are derivable in a chained manner, a first of the set of challenges being derivable by applying the derivation function to the master challenge, and each successive challenge in said set being derivable by applying the derivation function to a preceding challenge in the set.
 24. The method of claim 1, wherein the challenges of the set are derivable in a hierarchical manner, a first subset of the set of challenges being derivable by applying the derivation function to the master challenge, and each of one or more successive subsets being derivable by applying the derivation function to one of the challenges further back in the hierarchy.
 25. The method of claim 1, wherein the derivation function or an indication thereof is also stored in the data store, thereby making the derivation function or indication thereof available to the one or more verifying parties.
 26. The method of claim 1, wherein the derivation function is pre-known to at least one of the verifying parties and does not need to be made available or indicated to the at least one verifying party.
 27. The method of claim 1, wherein: the one or more verifying parties are a plurality of verifying parties; the set of challenges is a plurality of challenges, and the set of responses is respective plurality of responses; and the storing makes only a respective subset of one or more of the pieces of response data available to each of the verifying parties, with different subsets being made available to different ones of the verifying parties. 28-29. (canceled)
 30. The method of claim 27, wherein the subsets are exclusive of one another.
 31. The method of claim 1, wherein each of the response data comprises an explicit value of the respective response but are stored in the data store only in encrypted form.
 32. (canceled)
 33. The method of claim 31, wherein: each of a plurality of subsets of one or more of the response data records is individually encrypted, each subset requiring a different respective decryption key to decrypt; and the different subsets are made available to different ones of the verifying parties by distributing different ones of the decryption keys to different verifying parties.
 34. (canceled)
 35. The method of claim 1, wherein each of the pieces of response data comprises only an attestation of the respective response, not an explicit value of the response, the attestation comprising a transformation of the respective response which does not disclose the response, but which enables a verifying party to verify the identity of the target by performing the same transformation on a further instance of the respective response returned by the target and comparing with the attestation.
 36. The method of claim 35, wherein the transformation comprises a hash or double hash.
 37. (canceled)
 38. Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when run on the processing apparatus, the processing apparatus performs a method of enabling one or more verifying parties to verify an identity of a target comprising a target party or device of the target party; the method comprising, in a set-up phase: storing, in a data store, a respective piece of response data for each of a set of one or more responses resulting from a setting-up party inputting a respective set of one or more challenges into a PUF module comprising a physically unclonable function, PUF, to generate the one or more responses based on the PUF; and storing an indication of the set of challenges in the data store, wherein the indication does not comprise a value of each of the challenges in the set, but rather a master challenge from which the set of challenges is derivable by applying a derivation function to the master challenge; thereby making at least one of the pieces of response data and the respective master challenge available to the one or more verifying parties for verifying the identity of the target in a subsequent verification phase, wherein the respective piece of response data for each response comprises the respective response or data derived therefrom.
 39. A computer program product embodied on a non-transitory computer-readable medium and configured so as, when run on one or more processors, the one or more processors perform a method of enabling one or more verifying parties to verify an identity of a target comprising a target party or device of the target party; the method comprising, in a set-up phase: storing, in a data store, a respective piece of response data for each of a set of one or more responses resulting from a setting-up party inputting a respective set of one or more challenges into a PUF module comprising a physically unclonable function, PUF, to generate the one or more responses based on the PUF; and storing an indication of the set of challenges in the data store, wherein the indication does not comprise a value of each of the challenges in the set, but rather a master challenge from which the set of challenges is derivable by applying a derivation function to the master challenge; thereby making at least one of the pieces of response data and the respective master challenge available to the one or more verifying parties for verifying the identity of the target in a subsequent verification phase, wherein the respective piece of response data for each response comprises the respective response or data derived therefrom.
 40. A computer-implemented method whereby a verifying party verifies an identity of a target comprising a target party or device of the target party; the method comprising, by the verifying party: accessing, from a data store, a piece of response data from among a set of response data records, each comprising either: a) a value of a response resulting from inputting a challenge into a PUF module comprising a physically unclonable function, PUF, associated with the target, or b) an attestation comprising a transformation of the response; accessing a master challenge from the data store, and deriving at least one of the set of challenges by applying a derivation function to the master challenge; sending to the target a request comprising the at least one challenge to the target, and in response receiving back a further instance of the response; performing a comparison and verifying the identity of the target on condition that the comparison results in a match, wherein the comparison comprises: in the case of a) the stored value of the response matches the further instance, or in the case of b) the attestation matches the same transformation applied to the further instance. 41-44. (canceled) 